公開読書メモ・書評¶

2024-12 serverless-apps-on-cloudflare¶

• GitHub

2024-11 達人に学ぶDB設計徹底指南-第2版¶

6章まではだいたい知っている内容でもう読む必要はないだろう.

8.1節でサロゲートキーがグレーノウハウになっていた. 確かに業務上意味がないIDを使う機会は大量にあり, 実際にこれまでもよく使ってきた. これが原理的にはグレー判定なのは頭に入れた方がいいのかもしれない.

9章のツリーの話ははじめて見かけて面白かった. 出会うことがあれば参考にしよう.

2024-08 State Monad For The Rest Of Us¶

• State Monad For The Rest Of Us
• GitHub

part1¶

• URL
• バイナリツリー

2024-08 渡辺澄夫ベイズ理論100問with Python/Stan¶

2024-08 西林克彦 わかったつもり～読解力がつかない本当の原因～¶

• URL

「行間を読む」という特殊能力を見事に解剖した本。久々に鳥肌が立ちました。

メモ¶

(Kindle の位置No.312-318)

• ここまでの「わからない」「わかる」「よりわかる」に関する知見をまとめておきましょう。
  1. 文章や文において、その部分間に関連がつかないと、「わからない」という状態を生じます。
  2. 部分間に関連がつくと、「わかった」という状態を生じます。
  3. 部分間の関連が、以前より、より緊密なものになると、「よりわかった」「よりよく読めた」という状態になります。
  4. 部分間の関連をつけるために、必ずしも文中に記述のないことがらに関する知識を、また読み手が作り上げた想定・仮定を、私たちは持ちだしてきて使っています。

(Kindle の位置No.372-373): 後から考えて不充分だというわかり方を、「わかったつもり」とこれから呼ぶ. 「わかったつもり」が、そこから先の探索活動を妨害する.

(Kindle の位置No.415-416): 何の話かがわからなければ、話はわからない.

(Kindle の位置No.431-432): 一般的にこのように、あることがらに関する、私たちの中に既に存在しているひとまとまりの知識を、心理学、とくに認知心理学では「スキーマ」と呼びます どの「スキーマ」を使えばよいのかわからない.

(Kindle の位置No.448-451): その場に応じてある部分の知識を持ちだしてくること、または、全体の知識の一部分にスポットライトを当てて使えるようにすることを、「活性化」と呼びます。記憶の、ある領域を事前に活性化しておくと、その部分の反応が早くなるという、「プライミング」などと呼ばれる実験の分野が心理学にあったりもします。

(Kindle の位置No.454-455): 「何の話かわからないと、文章がわからない」といったように、ここまで「何の話」という言葉を使ってきましたが、これを認知心理学では、「文脈」と呼びます。

(Kindle の位置No.467-468): 先ほどの文章について、訳がわからなかったのは、「文脈」がわからず、したがって、「スキーマ」の発動のしようがなかったから

(Kindle の位置No.471-472): 絵がないとわからない話, もうひとつ、「文脈」のわからない文章を読んでいただきましょうか. (文脈は図として提供されている.)

(Kindle の位置No.512-514): 文脈によってどのスキーマを使用すべきかが明らかになった後に、その文脈のもとで、スキーマが文脈から得られる情報と共同して働く.

(Kindle の位置No.539-540): 文脈がより細かく指定されると、それだけ多くのスキーマが発動されやすくなる

(Kindle の位置No.550-551): それらは、読みとられることではあっても、書かれてあることではないのです。 そのような意味は、文脈によって引き出されているのです。

わかった状態になる：各部分から「文脈と矛盾なく関連がつき, 文脈を介して他の部分とも矛盾なく関連がつく意味」が引き出されている.

文脈によって全く違う意味が引き出される場合がある：本文の失業者・株仲買人と思ったときの対比.

(Kindle の位置No.600-604)

二章の要約.

1. 文脈がわからないと「わからない」
2. 文脈がスキーマを発動し、文脈からの情報と共同してはたらく
3. 文脈がそれぞれの部分の記述から意味を引き出す
4. 文脈が異なれば、異なる意味が引き出される
5. 文脈に引き出されたそれぞれの意味の間で関連ができることで文がわかる

「わかる」から「よりわかる」うえで必要なのは「わかったつもり」の乗り越え.

(正倉院と仏教の関係について)正答するかどうかではなく, 文章における「全体の雰囲気」は魔力を持っている. 「全体の雰囲気」が「部分の記述」から「全体の雰囲気」に都合のよい「意味を引き出し」てしまう.

「矛盾」や疑問は「よりよくわかる」ための契機で, 「認識の進展」からはよい存在.

間違っているのになぜ「わかったつもり」でいられるのか.

「読み飛ばし」現象に対する考察, 「文脈」の「侵入」現象.

全体の大雑把な文脈を打ち破るほどに部分が読み込まれていないため間違った状態が維持される. 部分の読みが不十分・間違っていると間違った「わかったつもり」が成立する.

• 人は文脈を使って部分を読む.
• 間違いは部分の読みの甘さから起こる.

文章の構成そのものから読み手がミスリードされやすい「わかったつもり」が存在する. 例：「小さなリスの大旅行」に対する読み.

• 「『結果から』というわかったつもり」：「ニャーゴ」の例.
• 「『最初から』というわかったつもり」は変化の面白さ・玄妙を味わえなくしてしまう.
• 「『いろいろ』というわかったつもり」：「いろいろある」と認識するとそれ以上の追求をやめてしまう.
  • うまく分類・整理できそうにないと「いろいろある」という言い訳が使われるのではないか.

「ステレオタイプのスキーマの魔力」：木下順次の「夕鶴」の例. 民話『鶴の恩返し』の知識・「恩返し」スキーマの影響. ステレオタイプ化された『勧善懲悪』や寓話的枠組みでの読み取りが生じる可能性.

読み手が自分の持っている「ステレオタイプのスキーマ」を文章に粗雑に当てはめてしまい, 間違った「わかったつもり」, 不十分な「わかったつもり」を作り出す.

ステレオタイプのスキーマと高瀬舟の感想. 「善きもの」の魔力・当てはめ.

「無難」の魔力.

「当たり障りのない」スキーマ. 「情緒的で価値判断的なスキーマ」, 「社会や自然理解に関わるスキーマ」. 出現の機制の理解は「魔力」への対応を考える上で重要.

「わかったつもり」の壊し型. その状態をどう認識するか?

• 自分でまとめてみる.
• あまりに簡単であった場合, 「ステレオタイプのスキーマ」に搦め捕られている可能性がある.
• 「内容は, ああ, あれだな」と思ったときは要注意.
  • 文章構成にミスリードされた魔物に搦め捕らている
• 慣れ親しんだスキーマを意識しながら文章にあたる.
• 変化の過程を読み飛ばしていないか?
  • 「結果から」わかったつもり
  • 「最初から」わかったつもり
• 各種事例やできごとが個別の特徴を伴って思い出せない
  • 「いろいろ」というわかったつもり
• 「どうも通りのよい, 当たり障りのない解釈・読み取りをしているのではないか」
  • 「ステレオタイプのスキーマ」
  • 文章を読んで概略や解釈を述べるとき, 「当たり障りのない綺麗事」が出てきたら要注意
  • 記述のまとめと例示は対応しているか
  • 文中のことがらは本当に事例になっているか?
• 「魔物」という大雑把な文脈に変えて, もっと部分に焦点が当たる新たな文脈を導入する

状態の進展

1. 「わかったつもり」の状態
2. 新たな文脈による部分からの新しい意味の引き出し
3. 引き出された意味による矛盾・無関連による「わからない」状態
4. 新たな無矛盾の関連づけによる「よりわかった」状態

文脈の交換で新しい意味が引き出せる. これはその文脈を使わなければ意味が見えないとも言える. 気に留めて積極的に問うたことしか見えず, それ以外は「見えていない」.

部分の間の関連を見つけるために大事な作業の分解

a. 物事についての客観的な事実に関する情報・知識の獲得 b. 読み手による想定・過程：「解釈」

「4.まとめ」で文中での種々のまとめが並べられている.

より細かな文脈を櫛し「わかったつもり」にあたる.

2024-08 C#ユーザーのためのWebアプリ開発パターン-ASP.NET_Core-Blazorによるエンタープライズアプリ開発¶

基本的なBlazorの枠組み¶

• 静的サーバー側レンダリング(Static SSR)
  • Blazor Unitedとしてアプリを開発する必要があるため次の指定が必要.
    • Interactive render mode = Auto (Server and WebAssembly)
    • Interactivity location = Per page/component
  • Static SSRを利用したい場合は@attributeや@rendermodeを指定しない
  • ストリームレンダリング機能付きStatic SSRには次の特性がある
    • SignalR回線を利用しない.
    • ページ描画後にサーバー側リソースを使わない.
    • イベントハンドラとして利用できるのはOnInitializedAsync()のみ.
    • 他のイベントハンドラ(たとえばボタン押下などのイベントハンドラ)は記述しても動作しない
• 対話型WebAssembly(Interactive WebAssembly, Blazor WASM)
• 対話型Server(Interactive Server, Blazor Server)
  • P.83参照
  • Interactive render mode: Server
  • Interactivity Location: Global
• 対話型Auto(Interactive Auto)
• Interactive render mode：利用するレンダリングモードの種類を指定する
• Interactivity location：レンダリングモードを設定する場所を指定する (グローバルはアプリ全体で特定のレンダリングモードだけを利用)
• Blazor Unitedを使うときの設定
  • Interactive render mode = Auto (Server and WebAssembly)
  • Interactivity location = Per page/component

Blazorでの指定の意味

• レンダリングモード：Per page/component指定時は設定値に応じてoのモードが利用可能.
• インタラクティビティの場所
  • Per page/component：個々に指定して使い分ける
  • Global：全てのページで特定のレンダリングモードを利用

レンダリングモード・インタラクティビティの指定によるプロジェクトの変化

• プロジェクトファイルが二つになるか否か
  • {Interactive render mode}としてWASMを利用しないタイプ(Noneまたは{Interactive Server})を選ぶと一つのプロジェクトだけ
  • Interactive render modeとしてWASMを利用するタイプ(Interactive WebAssemblyまたはInteractive Auto)を選ぶと二つのプロジェクトを利用
• Blazorランタイムに組み込まれる機能
  • Interactive render modeとしてServerを利用するタイプ(Interactive ServerまたはInteractive Auto)を選ぶと, Program.csファイルでInteractive Serverを利用するためのサービスやモジュールが追加される
  • Interactive render modeとしてWASMを利用するタイプ(Interactive WebAssemblyまたはInteractive Auto)を選ぶと, Program.csファイルでInteractive WebAssemblyを利用するためのサービスやモジュールが追加される
• 既定のレンダリングモードの指定
  • Interactivity locationとしてGlobalを指定すると, App.razorファイルの<HeadOutlet>と<Routes>に既定のレンダリングモードが指定される
  • Interactivity locationとしてPer page/componentを指定すると, App.razorファイルの<HeadOutlet>と<Routes>に既定のレンダリングモードが指定されず, 個々のファイルで必要に応じて指定する

利用するレンダリングモードによって、ファイルの置き場所を変える必要がある - WASM, Autoモードを利用するファイルはクライアント側のプロジェクトに入れる - Static SSR, Serverモードを利用するファイルはサーバー側のプロジェクトに入れる - Autoモードのページはクライアント側のプロジェクトに入れる - コンパイルすると当該ページはサーバーとクライアント(ブラウザ)の両方に配置される - そのうえで初回はサーバー側で動作し, 二回目以降(キャッシュ完了後)はブラウザ側で動作する - マスターページ(MainLayout, NavMenu)はサーバー側プロジェクトで定義する - マスターページの中のコンテンツブロックがStatic SSR, Server, WASM, Autoに切り替えられて動作する形になっている - マスターページは作成上の制限事項が発生する

メモ¶

データバインドモデル：UI描画に必要なUI要素のプロパティ情報を変数として定義する.

• データバインドでUI要素と変数を適切に紐づける(片方向あるいは双方向)
• イベントハンドラからはUI要素ではなく変数を操作する

データバインドには片方向データバインドと双方向データバインドがある.

• 片方向データバインドは主にUI要素へのデータの書き込み
• 双方向データバインドは主にUI要素からのデータの読み取り

「画面」・「変数」・「処理」を明確に分離して書くのが重要.

2.3.4 手動で描画を更新しなければならない場合

イベントハンドラがBlazorの画面のイベントハンドラではない場合, Blazorランタイムはデータバインドの再評価(再描画)の必要性を正しく把握できない. 処理の中で明示的にthis.StateHasChanged()を呼び出す必要がある.

• ASP.NET Core Razorコンポーネントのライフサイクル

双方向データバインドはテキストボックスやチェックボックス, ドロップダウンリストなどユーザーからデータ入力を受け付けるUI要素で利用.

ドロップダウンリストのデータバインドでは, 一覧表示に利用するコレクションデータと選択された項目のキー値を取得するための文字列型変数の二つが必要. 前者には片方向データバインドを, 後者には双方向データバインドを利用する.

• ASP.NET Core Blazorのイベント処理

asyncメソッドとしてイベントハンドラを記述するなら戻り型はTask型でなければならない.

2.6.1 null 値の取り扱いの設計方針

• 原則としてデータバインド, 特に双方向データバインドでは利用するデータ変数にnullを入れない. データ変数に対しては初期化処理を記述する.
• データバインドに利用するデータ変数にnullを入れる場合は, どのような意味を持たせるのかをはっきりさせる. 通常は「DBなどからデータを取得中である」という意味を持たせることが多い. データバインドに利用するデータ変数にnullを入れることがあると決めたら, データ変数をnull許容参照型として定義するとともに, データ変数がnullになる可能性を考えて記述する.

OnParameterSet()メソッドをきちんと使おう.

DataAnnotationsを使ったモデル検証機能によるViewModelクラスの実装.

3.2.3 各ページへのナビゲーション方法

画面遷移は次の二通り.

• ハイパーリンク利用
• NavigationManagerサービス利用

Blazor WASM型アプリの場合での画面間でのデータ引き渡しの方法については第10章で解説.

4.6.2 モデル検証機能による単体入力テストの実装方法

5.6.5 集約例外を用いたロギングのカスタマイズ方法

既定ではアプリで発生した未処理例外はコンソールなどに出力される. 追加でフラットファイルに保存するとよい. カスタムロガーを開発すればよく, 具体的なやり方はリスト5.14(P.112).

次回：6.2.1から.

2024-08 CSS in Depth, Second Edition¶

• Manning Livebook
• GitHub

ダークバージョン・レスポンシブにどう対応するかをきちんと見る.

1 カスケード、特異性、継承 メモ¶

• URL

以下の記述がCSSの宣言(declaration). 宣言はプロパティpropertyと値valueからなる The following declaration comprises a property (color) and a value (black):

1

color: black;

プロパティとHTMLの属性attributeを混同しない. セレクターと宣言ブロックを合わせてルールセットruleset. @mediaや@importなどのat-rulesは言語構造.

リンクに関する設定順序

• LoVe/HAte (リンク, 訪問済み, ホバー, アクティブ)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

a:link {
  background-color: blue;
  color: white;
  text-decoration: none;
  padding: 2px;
}
a:visited {
  background-color: purple;
}

a:hover {
  background-color: transparent;
  color: blue;
  text-decoration: underline;
}

a:active {
  color: red;
}

歴史的にカスケードの操作には2つの一般的な経験則があります. まずセレクターでIDを使用しないでください. 2番目に!importantを使用しないでください. これらの両方により将来必要になった場合にスタイルのオーバーライドが難しくなります.

bodyへのfont-familyなど継承をうまく使うべき対象がある.

inherit, initial, unset, revert.

短縮プロパティは余計なデフォルト値まで一緒に設定してしまう場合がある. 混乱を引き起こさないようにするためなるべく必要な値だけ指定するようにした方がよい.

特に小さい要素では上部と下部よりも側面のパディングを多くする方が良い場合がある.

特定の機能をサポートしているブラウザのバージョンを確認するにhttps://caniuse.com, またはMDNの関連ドキュメントページを確認.

@supports

2 相対単位の使用¶

• URL

ピクセル、ポイント、パイカ

1 インチ = 25.4 mm = 101.6 Q = 2.54 cm = 6 pc = 72 pt = 96 ピクセル

レスポンシブ デザインについては第8章.

2.2 エムとレム

最も一般的な相対長さの単位であるEmsはタイポグラフィで使用される尺度で, 指定されたフォント サイズを指す. CSSで1emは現在の要素のフォントサイズ. 正確な値はそれを適用する要素によって変わる.

1
2
3
4

.padded {
  font-size: 16px;
  padding: 1em;
}

相対単位を使用して宣言された値はブラウザによってcomputed value(計算値)と呼ばれる絶対値に評価される. emsを使用すると次のようなプロパティを設定するときに便利: padding, height, width, border-radius.

ほとんどのブラウザではデフォルトのフォントサイズが16px. 技術的にはmediumキーワードの値.

emsが扱いにくいのは同じ要素のフォントサイズとその他のプロパティの両方にemsを使用する場合で, ブラウザは最初にフォントサイズを計算し, 次にその値を使用して他の値を計算する. 両方のプロパティは同じ宣言値を持てるが計算値は違う.

• 図 2.5 フォント サイズ 0.8em をネストされたリストに適用するとテキストが縮小する

ありがたいことにより良いオプションremsがある. レムremは「ルートエム」の略称.

1
2
3
4
5
6

:root {
  font-size: 1em;
}
ul {
  font-size: 0.8rem;
}

著者のデフォルトではフォントサイズにはrems, 境界線にはピクセル, その他のほとんどの測定値、特にパディング・マージン・境界線の半径にはemまたはremsを使用します.

デフォルトのフォントサイズは一部のユーザー, 特に視覚障害のあるユーザーにとって重要であるため, フォントサイズは常に相対単位またはパーセンテージで指定する必要がある.

2.3 ピクセル単位で考えるのをやめる

過去に一般的だった 1 つのパターン, つまりアンチパターンはページのルートのフォント サイズを 0.625 em または 62.5% へのリセット. これでブラウザのデフォルトのフォント サイズの16ピクセルが10ピクセルに縮小される. この慣習で計算が簡素化される.

このアプローチには2つの問題がある. 重複したスタイルを多数記述する必要がある. 10ピクセルはテキストとしては小さすぎるためページ全体でこれをオーバーライドする必要がある. エラーが発生する場所が増え, コードを変更する必要がある場合の連絡先が増え, スタイルシートのサイズが増える.

2番目の問題は依然としてピクセル単位で考えている点. レスポンシブWebでは「あいまいな」値に慣れる必要がある. 1.2 em が何ピクセルに評価されるかは問題ではない.

リスト 2.9 真のデフォルトのフォント サイズの設定

1
2
3

:root {
  font-size: 0.875em;
}

上記の設定下でのパネルのマークアップ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

<div class="panel">
  <h2>Single-origin</h2>
  <div class="panel-body">
    We have built partnerships with small farms around the world to
    hand-select beans at the peak of season. We then carefully roast
    in <a href="/batch-size">small batches</a> to maximize their
    potential.
  </div>
</div>

.panel {
  padding: 1em;
  border-radius: 0.5em;
  border: 1px solid #999;
}

.panel > h2 {
  margin-top: 0;
  font-size: 0.8rem;
  font-weight: bold;
  text-transform: uppercase;
}

セレクター.panel> h2の>は直接の子孫のコンビネーターを表す.

リスト 2.12 レスポンシブの基本フォントサイズ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

:root {
  font-size: 0.85em;
}

@media (min-width: 800px) {
  :root {
    font-size: 1em;
  }
}

@media (min-width: 1200px) {
  :root {
    font-size: 1.15em;
  }
}

2.4 ビューポート関連の単位

ビューポートはWebページが表示されるブラウザ ウィンドウ内の枠で囲まれた領域.

• 基本ビューポート
  • vh: ビューポートの高さの1%
  • vw: ビューポート幅の1%
  • vmin: 小さい方の寸法、高さ、または幅の1%
  • vmax: 大きい方の寸法、高さ、または幅の1%
• 大きなビューポート単位を使用するには文字「l」を先頭に追加する: lvw, lvh, lvmin, lvmax.
• 同様に小さなビューポート単位を使用するには文字「s」を先頭に追加する: svw, svh, svmin, svmax
• ブラウザの UX 要素が表示または非表示になったときに動的にシフトする, ビューポート ユニットの本来の動作が必要な場合はダイナミックビューポート: dvw, dvh, dvmin, dvmax.

ダイナミック ビューポート ユニットは慎重に使用する必要がある. モバイル デバイスのユーザーが上下にスクロールすると, 要素の高さが動的に変化するとレイアウトのスラッシングが発生する可能性がある.

追加のユニットタイプのセット(インラインとブロック)がある. これらは「論理プロパティ」と呼ばれ, それぞれ幅と高さと同様に動作する. 日本語などの縦書き言語では置き換えられる. 論理プロパティは第3章.

2.4.2 フォント サイズにビューポート単位を使用する

すぐには分からないかもしれないビューポート相対単位の応用例の1つはフォント サイズ.

calc()関数で応答性を高める. 加算演算子と減算演算子は空白で囲む必要がある. 例：calc(1em + 10px).

clamp()は最小値・式としての推奨値・最大値の3つの引数を取る.

フォントサイズがレスポンシブになったため, emsまたはremsを使用して定義されたページ上の他のサイズも同様にレスポンシブに拡大縮小される. メディア クエリを1つも使わずにレスポンシブ戦略の大部分を達成できる.

2.5 単位のない数値と行の高さ

一部のプロパティでは単位のない値(つまり単位が指定されていない数値)が使える. これをサポートするプロパティとしてline-height, z-index, font-weight. 700は太字に相当し, 400は標準に相当. 単位のない値として長さの0がある.

2.6 カスタム プロパティ (別名 CSS 変数)

色の定義にも便利.

変数宣言の例

1
2
3
4
5
6
7

:root {
  --main-font: Helvetica, Arial, sans-serif;
}

p {
  font-family: var(--main-font);
}

2.6.1 カスタムプロパティを動的に変更する

カスタムプロパティの宣言はカスケードおよび継承される. 複数のセレクター内で同じ変数を定義でき, その変数はページのさまざまな部分で異なる値を持つ. たとえば変数を黒として定義し, 特定のコンテナ内でそれを白として再定義できる. ダークバージョンに応用できる.

2.7 概要

• 相対単位を使用して、フォント サイズまたはビューポート サイズに適応するサイズを指定できます。
• emは要素のフォント サイズを基準にして長さを定義します。ただし、フォント サイズ自体を指定する場合は除きます。この場合、em は要素の継承されたフォント サイズを基準とします。
• Rems は、ルートで指定されたフォント サイズに関して長さを定義します。
• レスポンシブ デザインでルート フォント サイズを拡大縮小すると、ems と rems を使用して定義されたページ上の要素も同時に拡大縮小されます。
• ビューポート相対単位は、ビューポートの幅または高さに関して長さを定義します。
• 単位のない数値で定義された行の高さは、より予測どおりに子要素に継承されます。
• カスタム プロパティは変数と同様に機能しますが、カスケードと継承を通じて動的に操作できます。

3 ドキュメントフローとボックスモデル¶

イントロダクション¶

• ページ レイアウトを構築するための一般的なヒント
• 要素のサイジングに関する実践的なアドバイス
• 論理プロパティの概要
• マイナスのマージンとマージンの崩壊
• ページ上のコンポーネントの一定の間隔

レイアウトのより高度なトピックはドキュメント フローやボックス モデルなどの概念に基づいて構築されています. これらはページ上の要素の位置とサイズを決定する基本的なルールです.

この章では基本的な一列のページ レイアウトを構築. 見落とされがちなレイアウトの微妙な点に焦点を当てて説明する. ボックス モデルのエッジケースを見る.

3.1 通常のドキュメントの流れ¶

inlineとblockで動作が違う.

インライン要素：ページのテキストとともに左から右に流れ, コンテナの端に達するとラインが折り返される.

ブロック要素(通常は「ブロ​​ックレベル」要素と呼ばれる)：それぞれ独立した行に表示される. コンテナの幅を自動的に埋める. 幅を減らすためにスタイルを追加しても上下に改行が入る.

通常のドキュメントフロー：ページ上の要素のデフォルトのレイアウト動作を指す.

注意すべき重要な点：高さと幅が根本的に異なる. 通常のドキュメントフローは制限された幅と無制限の高さで機能するように設計されている.

親要素の幅によって子の幅が決まる一方, 高さはその逆で, 子要素の高さで親の高さが決まる. 結果としてそれぞれを操作するために異なるアプローチが必要.

3.1.1 コンテンツを水平方向に中央揃えにする

ページのレイアウトを開始するには外側から内側に向​かうのが最善.

3.1.2 論理プロパティの使用

• 論理プロパティの包括的なリスト

論理プロパティ：上下左右または幅と高さを明示的に参照するのではなく, ブロック方向とインライン方向(書き込みモードによって変わる可能性があり)に関して要素を操作する方法を提供する.

縦横概念を柔軟にするため, 例えば次のような読み替えが起きる. 本のFigure 3.5も参照すること.

• padding-left - padding-inline-start
• padding-right - padding-inline-end
• border-top - border-block-start
• border-bottom - border-block-end

3.1.3 便利な短縮論理プロパティの採用

3.2 ボックスモデル¶

Figure 3.7, デフォルトのボックスモデル 内側からContent - Padding - Border - Margin.

3.2.2 ボックスモデルの調整

box-sizingプロパティの理解が重要.

ユニバーサルボーダーボックスの修正. 2024年時点では以下の設定を追加するのが一般的.

1
2
3
4
5

*,
::before,
::after {
  box-sizing: border-box;
}

3.3 要素の高さ¶

3.3.1 オーバーフロー動作の制御

要素の高さを明示的に設定するとその内容がコンテナからオーバーフローする危険がある. overflowプロパティを適切に設定する必要がある. 特に意図がなければautoを使うとよい.

3.3.2 パーセンテージベースの高さの代替手段の使用

パーセンテージを使用して高さを指定すると問題が発生する可能性がある. パーセンテージベースの高さを機能させるには, 親の高さが明示的に定義されている必要がある.

開発者がパーセンテージの高さを使用しようとして問題を引き起こすケースが特に 2 つある.

1. コンテナを画面いっぱい表示する場合. より良いアプローチは, 第2章で説明したビューポート相対単位の利用.
2. 同じ高さの列の作成. 次章のフレックスボックスとグリッドで議論.

3.3.3 min-height と max-height の使用

3.4 マイナスのマージン¶

要素のオーバーラップやコンテナより広く拡張するいくつかの特殊な用途がある.

負のマージンで複数の要素間にオーバーラップを生じさせられても, 複雑な対象相手では難しい. 多くの場合はpositionを利用する. ポジショニングは第6章で詳述.

負のマージンを使用して要素を重ねると, インタラクティブな要素が他の要素の後ろに移動した場合にクリックできなくなる可能性がある.

3.5 マージンの縮小¶

3.5.1 テキスト間の折りたたみ

3.5.2 複数のマージンを折りたたむ

3.5.3 コンテナ外での折りたたみ

マージンを完全に削除し, パディングで必要なスペースを定義するのがおそらく最善.

• overflow: auto(またはvisible以外の値)をコンテナーに追加して, コンテナー内のマージンがコンテナーの外側のマージンと崩れるのを防ぐ. 多くの場合これは最も煩わしくない解決策.
• 二つのマージンの間に境界線またはパディングを追加するとマージンが崩れるのを防ぐ.
• インラインブロック・フローティング(第12章), または絶対位置または固定位置(第6章)を持つコンテナーの外側にはマージンは折りたたまれない.
• フレックスボックスまたはグリッド レイアウトを使用する場合, フレックス レイアウトの一部である要素間でマージンは崩れない(第 4 章と第 5 章).
• table-cellが付いた要素などほとんどのテーブル表示タイプは余白がなく表示が崩れない. ただし例外table, table-inline, table-captionがある.

3.6 コンテナ内の要素の間隔¶

• +: 隣接兄弟コンビネータ
• さまざまなコンビネータの概要は付録A参照.

3.6.1 内容変更の検討

サイドバーにさらにコンテンツを追加するとすぐにスペースの問題が再び起きる.

3.6.2 より一般的なソリューションの作成

Webデザイナーのヘイドン・ピッカリングはかつて, マージンは「実際に何かに貼り付けるかどうか, あるいはそれが何なのかを決める前に, 物体の片面に接着剤を塗るようなものだ」と語った.

ロボトミー化された梟* + *.

1
2
3

.stack > * + * {
  margin-block-start: 1.5em;
}

3.7 概要¶

• 通常のドキュメントフローではインライン要素は横に並べて配置され, 必要に応じて行が折り返される. ブロックレベルの要素はそれぞれ独自の行に配置されてデフォルトでコンテナの幅を埋める.
• 論理プロパティは明示的な基本的な方向ではなく, ドキュメント フローの観点から要素の側面またはサイズをす.
• ボックス モデルはマージン・ボーダー・パディング・コンテンツが要素のサイズを定義する方法を記述する. box-sizing: border-boxを利用するとサイジングの動作がより直観的になる.
• 要素の高さは内容に基づいて有機的に決まる. 高さを明示的に設定するとオーバーフローの問題が起き得る.
• マージンがコンテナの外側の他のマージンと崩れて要素間に望ましくない間隔が生じる可能性がある. overflow: autoはこれを防ぐ一つの方法. 「ロボトミー化されたフクロウ」セレクターはブロックレベルの要素間にスペースを追加するのに便利なツール.

4 フレックスボックス¶

• flex boxを使用してページの要素をレイアウトする
• フレックスコンテナとフレックスアイテム
• 主軸と交差軸
• flex boxでの要素のサイズ変更
• flex boxでの要素の配置

4.1 フレックスボックスの原則¶

• display: flex;の追加でフレックスコンテナに変わる.
• display: inline-flexでinline-blockのように動作するフレックスコンテナができる.

4.2 フレックスアイテムのサイズ¶

4.3 フレックス方向flex-direction¶

垂直フレックスボックスを使用する場合(columnまたはcolumn-reverse), 行については同じ一般的な概念が適用される一方で留意すべき違いが一つある.

• CSSで高さの操作は幅の操作とは根本的に異なる.

フレックスコンテナの幅は利用可能な幅の100%になる. しかし高さはその内容によって自然に決まる. この動作は主軸を回転しても変わらない.

4.4 配置、間隔、その他の詳細¶

4.5 概要¶

• フレックス コンテナの子はフレックス アイテムになります。ブラウザは、フレックス項目を行または列に配置します。
• flexの短縮プロパティはflex-grow, flex-shrinkおよびflex-basisの値を指定してフレックス項目のサイズを決定する方法を指定します。
• フレックスボックスをネストして, より複雑なレイアウトをつなぎ合わせたり, 自然なサイズのボックスの高さを埋めることができます。
• Flexboxは同じ高さの列を自動的に作成します。
• Flexboxにはフレックス アイテムを無数の方法で位置合わせしたり間隔をあけたりできるようにするいくつかのプロパティが用意されています。
• align-itemsまたはalign-selfプロパティはフレックス コンテナ内のフレックス項目を垂直方向の中央に配置できます。

5 Grid layout¶

• グリッドを使用してページ レイアウトを構築する
• グリッド レイアウト オプションを理解する
• グリッド線と名前付きグリッド領域を使用してアイテムを配置する
• 明示的および暗黙的なグリッド
• フレックスボックスとグリッドを併用してまとまりのあるWebページレイアウトを構築する

FlexboxはWeb上でのレイアウトの全体像の一部. 兄貴分がグリッド レイアウト モジュール(Grid)と呼ばれる仕様で, これら二つの仕様を組み合わせてフル機能のレイアウト エンジンが提供される.

CSSグリッドで列と行の二次元レイアウトが定義でき, グリッド内に要素を配置できる. 一部の要素はグリッドの一つのセルだけを埋める場合がある. 他は複数の列または行にまたがれる. グリッドのサイズは正確な定義も, 内容が収まるように必要に応じてグリッド自体のサイズの自動調整もできる. アイテムのグリッド内への正確な配置もでき, 自然に流れて隙間を埋められる. 特にグリッドで図5.1に示す複雑なレイアウトを構築できる.

5.1 基本的なグリッドの構築¶

5.2 グリッドの構造¶

重要な四つの用語：grid line, grid track, grid cell, grid area

グリッドについて学んだ後, 開発者はフレックスボックスについてよく質問します. これら二つのレイアウト方法は競合するのでしょうか? 答えはノーです. それらは補完的です. これらは主に連携して開発されました. それぞれが達成できることには一部重複がありますが, それぞれが異なるシナリオで輝きます. デザインの一部としてフレックスボックスとグリッドのどちらを選択するかは特定のニーズに応じて決まります. 二つのレイアウト方法には次の二つの重要な違いがあります。

• フレックスボックスは基本的に一次元で, グリッドは二次元.
  • 参考：図.5.8
• フレックスボックスはコンテンツから出力されるのに対して, グリッドはレイアウトから入力される.

注記 グリッドとフレックスボックスはどちらもグリッド項目またはフレックス項目間でマージンが崩れるのを防ぎます. ギャップを追加するとユーザー エージェント スタイルによって追加されたマージンによって, 項目間のスペースが大きくなりすぎる場合があります. このページのいくつかの場所でマージンを0にリセットする必要があるのはこのためです.

5.3 代替構文¶

5.4 明示的グリッドと暗黙的グリッド¶

5.5 サブグリッド¶

5.6 整列プロパティ¶

5.7 概要¶

• グリッドは、ページの行ベースと列ベースのレイアウトを定義し、項目を相互に関連させて配置できるようにします。
• グリッドはフレックスボックスと連携して機能し、完全なレイアウト システムを提供します
• グリッド項目の配置は、番号付きグリッド線、名前付きグリッド線、名前付きグリッド領域の 3 つの構文のいずれかを使用して実行できます。どのような状況でも、レイアウトのニーズに合わせて最も直感的なものを使用できます。
• 自動入力/自動調整および暗黙的なグリッド配置は、多数のグリッド項目または不明な数のグリッド項目をレイアウトする場合にうまく機能します。
• サブグリッドは、単純な親子要素のセットよりも深くネストされた要素を整列できます。
• フレックスボックスと同じ配置プロパティがグリッドに適用されます。

6 コンテキストの配置と積み重ね¶

• 要素の配置のタイプ: 固定、相対、絶対、およびスティッキー
• モーダルダイアログとドロップダウンメニューの構築
• z-index とスタッキングコンテキストを理解する
• CSSで単純な三角形を描画する

6.1 固定位置¶

• position: fixed
• 短縮表現としてinsetがある.

6.1.1 固定位置でのモーダルダイアログ¶

いまHTMLには<dialog>要素がある. ここでは固定位置の動作をより詳しく説明するためにあえてこれを使っていない. dialogはMeet the New Dialog Elementを読むとよい.

6.1.2 モーダルダイアログが開いているときに画面がスクロールしないようにする¶

6.1.3 配置された要素のサイズの制御¶

6.2 絶対位置決め¶

• position: absolute

6.2.1 閉じるボタンの絶対配置¶

6.2.2 擬似要素の配置¶

ヒント: 「閉じる」ボタンでは文字xの代わりに, 乗算記号としてUnicode文字を使う方がよい. より対称的で見た目もより美しくなる. HTML文字×がこの文字としてレンダリングされる. CSSでcontent プロパティを利用するにはエスケープされたUnicode番号\00D7を適用する必要がある.

絶対位置決めは位置決めタイプの中で最も強力. これはメニュー・ツールヒント・「情報」ボックスをポップアップするため, JavaScriptと組み合わせて利用する. これを利用してドロップダウン メニューを作成する方法を説明する. そのためにまずそのコンパニオンである相対位置を確認する必要がある.

6.3 相対位置決め¶

相対位置決めはおそらく最も理解されていない位置決めタイプ.

注記：fixed・absoluteとは違ってinsetプロパティで相対的に配置された要素のサイズは変えられない.

6.3.1 ドロップダウン メニューの作成¶

アクセシブルなドロップダウンの構築の詳細はAccessible Custom Select Dropdownsを参照.

6.3.2 CSS トライアングルの作成¶

CSSで構築された多数の形状のリストはhttps://css-tricks.com/examples/ShapesOfCSS/を見るとよい. これらは特にSVGアイコンで不要になる場合もあるが, うまく使うと余計な要素のローディングを避けられる.

6.4 コンテキストの積み重ねとz-index¶

6.4.1 レンダリングプロセスとスタック順序を理解する¶

デフォルトでは位置決めされた要素はすべて位置決めされていない要素の前に表示される.

通常モーダルはコンテンツの最後の部分としてページの最後に追加される. 特にモーダル ダイアログを構築するためのほとんどのJavaScriptライブラリはこのように実装されている.

6.4.2 z-indexを使用したスタック順序の操作¶

z-indexはページのスタッキングの問題を解決するための第二の方法. z-indexは簡単そうに見えても二つ注意点がある.

• z-indexは位置決めされた要素に対してしか機能しない. 特に静的要素の積み重ね順序は操作できない.
• 位置決めされた要素にz-indexを適用するとスタッキング コンテキストが確立される.

6.4.3 スタッキングコンテキストの理解¶

スタッキング コンテキストのすべての要素が一緒にペイントされる. これには重要な影響がある.

スタッキング コンテキストの外側にある要素は, その内側にある二つの要素の間にスタックできない. 別の言い方をすると, 要素がスタッキング コンテキストの前にスタックされている場合, そのスタッキング コンテキスト内の要素をその前に置けない. 同じくページ上の要素がスタッキング コンテキストの背後にスタックされている場合, そのスタッキング コンテキスト内の要素をその要素の背後にスタックできない.

これを理解するのは簡単ではない. 「リスト 6.12 コンテキストのスタックの例」以降で説明用の最小限のシナリオを組み立てる方法を示す.

注記：z-indexの追加だけがスタッキング コンテキストを構成する方法ではない. transformまたはfilterプロパティと同じく, 1以下のopacityもその一つ. 固定配置とスティッキー配置(セクション 6.5)はz-indexがなくても, 常にスタッキング コンテキストをなす. ドキュメントルート(<html>)はページ全体の最上位のスタッキング コンテキストも作る.

変数を使用して Z インデックスを追跡する さまざまなコンポーネントの優先順位について明確な順序がないため, スタイルシートは簡単にz-index戦争に発展する. 明確なガイダンスがなければスタイルシートにモーダルのようなものを追加する開発者は, モーダルがページ上の他のものの背後に表示されないよう999999などの途方もなく高いz-indexインデックスを設定する可能性がある. これを制御するにはカスタム プロパティを有効活用する. すべてのz-index値を変数として一箇所にまとめる. これで何が前に表示されるかを一目で確認できる.

1
2
3
4
5

--z-loading-indicator: 100;
--z-nav-menu:          200;
--z-dropdown-menu:     300;
--z-modal-backdrop:    400;
--z-modal-body:        410;

10または100の増分を利用すれば必要に応じて間に新しい値を挿入できる.

明示的に何かを配置するのではなく, ドキュメント フローに作業を実行させられるなら, ブラウザーが多くのエッジ ケースを処理してくれる. 配置によってドキュメント フローから要素が取り除かれる点に注意する. 一般にこれは要素を互いの前に積み重ねる必要がある場合にだけ実行する必要がある.

6.5 スティッキーな位置決め¶

相対位置と固定位置のハイブリッドのようなもの. 要素は画面上の指定された点に到達するまでページとともに通常どおりスクロールし, その点でユーザーがスクロールを続けると, その点で所定の位置に「ロック」される. この一般的な使用例はサイドバー ナビゲーション.

6.6 概要¶

• 固定位置ではビューポートを基準にして要素が配置される.
• 相対配置では要素を初期の静的位置を基準にして配置する. ページ上の他の要素は引き続きその初期位置の周りを流れ続ける.
• 絶対配置では最も近い位置にある祖先要素を基準にして要素が配置される.
• 固定配置ではページの残りの部分がスクロールしても要素が画面上に留まる. それらは親要素内に含まれたまま.
• z-indexは位置決めされた要素に対してしか機能しない. 新しいスタッキング コンテキストが作られる.

7 レスポンシブデザイン¶

• 複数のデバイスと画面サイズに対応したWebページの構築
• メディア クエリを使用してビューポート サイズに基づいてデザインを変える.
• ページのスタイルを設定するときに「モバイル ファースト」のアプローチを採用する
• レスポンシブ画像の使用

レスポンシブの良い例：The Boston Globe.

レスポンシブ デザインの三つの重要な原則.

1. モバイルファーストのデザインアプローチ。 これはデスクトップ レイアウトの構築を開始する前にモバイル バージョンの計画があることを意味します。
2. @media：このルールを使用すると, さまざまなサイズのビューポートに合わせてスタイルを調整できます。 この構文(メディア クエリと呼ばれることが多い)を使用すると, 特定の条件下でのみ適用されるスタイルを作成できます.
3. 流動的なレイアウトの使用。 このアプローチによってコンテナーをビューポートの幅に基づいてさまざまなサイズに拡大縮小できます.

7.1 モバイルファースト¶

モバイル向けの開発は制約の中での作業です。 画面のスペースは限られています。 ネットワークが遅くなることがよくあります。 モバイル デバイスのユーザーは異なる対話型コントロールのセットを使用します。 タイピングは可能ですが面倒です。 ユーザーは要素の上にマウスを移動して効果をトリガーできません。 完全なインタラクティブなWebサイトの設計から始めてこれらの制約を満たすためにそれを縮小しようとすると, 多くの場合失敗します.

モバイル レイアウトはほとんどの場合飾り気のないデザインです. インタラクティブなメニューとは別に, このデザインはコンテンツに重点を置いています. 大きな画面ではヘッダー・ヒーロー画像・メニューなどに多くのスペースを割けます. しかしモバイル デバイスではユーザーはよりタスク指向になることがよくあります. 彼らは友達と外出していて, 店舗の営業時間や価格や住所などの特定の情報をすぐに見つけたいと考えているかもしれません.

重要：レスポンシブ デザインのHTMLを記述するとき, 各画面サイズに必要なものがすべて含まれているかの確認が重要です. インスタンスごとに異なるCSSを適用できる一方, すべて同じHTMLを共有する必要があります.

7.1.1 モバイルメニューの作成¶

ヒント：スクリーン リーダーはランドマークとしてform, main, nav, asideのような特定のHTML5要素を使用します. これで視力の弱いユーザーがページをすばやく移動できるようになります.

ハンバーガーメニューのデメリット：ハンバーガー メニューはモバイル デザインの一般的なアプローチです. 小さな画面にさらに多くを表示するという問題は解決できますが代償も伴います. 重要な要素(メイン ナビゲーション メニューなど)を非表示にすると, それらの要素に対するユーザーの操作が減少することがわかっています.

7.1.2 ビューポートメタタグの追加¶

7.2 メディアクエリ¶

7.2.1 メディアクエリの種類を理解する¶

ライトモードとダークモード

1
2
3
4
5
6

@media (prefers-color-scheme: dark) {
  :root {
    --theme-font-color: white;
    --theme-background: #222;
  }
}

1
2
3
4
5
6

@media (prefers-color-scheme: light) {
  :root {
    --theme-font-color: #222;
    --theme-background: #eee;
  }
}

7.2.2 ページへのブレークポイントの追加¶

ヒント：メディア クエリはオーバーライドする必要があるスタイルの後に配置します. こうするとメディア クエリ内のスタイルは, 同じセレクターの特性を持つ他のスタイルをオーバーライドできます.

7.2.3 レスポンシブ列の追加¶

7.3 流動的なレイアウト¶

7.3.1 大きなビューポート用のスタイルの追加¶

7.3.2 テーブルの処理¶

テーブルはモバイル デバイス上の流動的なレイアウトの場合に特に問題になります. テーブルに数個以上の列がある場合, 簡単に画面の幅をオーバーフローする可能性があります(図 7.10). 可能であればモバイル ユーザー向けにデータを整理する別の方法を見つけることをお勧めします. たとえば各行のデータを独自のタイルに移動し, タイルを互いに積み重ねることができます. あるいは小さなビューポートに適した視覚的なグラフやチャートを作成することもできます. ただしテーブルだけが必要な場合もあります.

7.4 レスポンシブ画像¶

レスポンシブ デザインでは画像に特別な注意が必要です. 画面に収まるようにするだけでなく, モバイル ユーザーの帯域幅制限も考慮する必要があります. 画像はページで使用されるリソースの中で最も大きなものの 1 つである傾向があります. 最初に行うべきは画像な十分な圧縮の確認です.

7.4.1 異なるビューポート サイズに対する複数の画像の使用¶

7.4.2 srcset を使用して正しいイメージを提供する¶

レスポンシブ画像の詳細はThe anatomy of responsive imagesにアクセスしてください.

レスポンシブ デザインでのページの領域の構造化は無数の方法で行うことができます. それらのいずれかを構築するにはモバイル ファースト・メディア クエリ・流動的なレイアウトの三原則を適用する必要があります. これらの原則を理解すると, ページを構築する際にレスポンシブなニーズを念頭に置くのに役立ちます.

このアプローチはかなり長い間効果的であることが証明されています. ただしこのリストに追加すべき重要なツールが一つあります. それはコンテナー クエリです. これは開発者が数年間楽しみにしていた CSS の最近の機能です. 次の 2、3 章で役立つ基礎を築き, 第 10 章でレスポンシブ デザインのトピックに戻ってこの機能を議論します.

7.5 概要¶

• 「モバイルファースト」の考え方でデザインに取り組むと, レスポンシブデザインの実装が容易になります. 一般にモバイル ページを大きな画面へのスケールアップは, デスクトップ ページをモバイルにスケールダウンするよりも簡単です.
• メディア クエリを使用すると, ビューポート サイズやユーザー環境のその他の側面に基づいてCSSを条件付きで適用できます. これを使用してより大きなビューポートでページを段階的に強化します.
• 流動的なレイアウトはどのブラウザ サイズでも常に画面にフィットします.
• レスポンシブ画像はモバイル デバイスの帯域幅制限に対応するのに役立ちます.
• メタ ビューポート タグはサイトがレスポンシブに設計されていることをブラウザーに伝えます. これでスタイルが期待どおりに小型デバイスに適用されるようになります.

8 カスケードレイヤーとネスト¶

• CSSを論理的に整理する
• レイヤーを使用してカスケードを制御する
• :is()と:where()疑似クラスの使用
• 関連するスタイルをネストしてグループ化する

これまで開発者がこれらの問題に対処できる唯一の方法は, 厳密に規定された方法論と命名パターンの利用使用でした. しかしCSSにはこの点で役立ついくつかの新しい機能があります. これらはコード編成の優れた手段とカスケードの明示的な制御を提供する第一級の機能です.

これらの各機能について説明する際に現在のブラウザーのサポートについても説明しますが, これを読む際には最新の統計を必ず確認してください. これに適した二つのリソースは次の通りです.

• https://developer.mozilla.org/
• https://caniuse.com/

8.1 レイヤーを使用したカスケードの操作¶

8.1.1 レイヤーの定義¶

最新のCSSでこれを管理するより良い方法はカスケード レイヤー. レイヤーを使用したいがブラウザーのサポートが心配な場合https://www.oddbird.net/2022/06/21/cascade-layers-polyfill/を参照.

@layer

匿名レイヤー：レイヤーに名前を付けると一般にもう少し柔軟性が高まります.

@importで外部スタイルシートをインポートすると, そのスタイルシートをレイヤーに割り当てられます. 例えば@import "bootstrap.css" layer(bootstrap); bootstrap.cssでbootstrap.cssをbootstrapという名前のレイヤーにインポートします.

8.1.2 レイヤーの順序と優先順位¶

同じレイヤー名をもう一度参照すると, スタイルシートですでに確立されているレイヤーにさらにスタイルを追加できます.

CSSの次の行では優先順位の高い順に4つのレイヤーを宣言しています.

1

@layer reset, global, theme, components;

すべてのレイヤーをスタイルシートの最初でこのように宣言することを強くお勧めします. これで優先順位が明確になり, 見つけやすくなります.

レイヤー内で!importantを使用する¶

入れ子になったレイヤー¶

ネストされたレイヤーによって, そのスタイルシートで定義されているレイヤーを無効にせず, サードパーティのスタイルシートをレイヤーにインポートできる.

8.1.3 revert-layer キーワード¶

すべてのプロパティ¶

allという便利な短縮プロパティがあります.

8.2 カスケード層の推奨構成¶

1

@layer reset, theme, global, layout, modules, utilities;

8.2.1 レイヤのリセット¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

@layer reset, theme, base, layout, modules, utilities;

@layer reset {
  *,
  *::before,
  *::after {
    box-sizing: border-box;
  }

  body {
    margin: unset;
  }

  button,
  input,
  textarea,
  select {
    font: inherit;
  }

  img,
  picture,
  svg,
  canvas {
    display: block;
    max-width: 100%;
    height: auto;
  }

  @media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
      animation-duration: 0.01ms !important;
      animation-iteration-count: 1 !important;
      transition-duration: 0.01ms !important;
      scroll-behavior: auto !important;
    }
  }
}

8.2.2 テーマレイヤー¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

@layer theme {
  :root {
    --brand-color: #0063cc;
    --background-color-1: #edf3fa;
    --background-color-2: #c6cdd5;
    --foreground-color-1: #39434d;
    --foreground-color-2: #5a636d;
    --font-main: "Helvetica Neue", "Nimbus Sans", Arial, sans-serif;
    --font-heading: Georgia, sans-serif;

    accent-color: var(--brand-color);
    color-scheme: light;
  }
}

8.2.3 グローバル層¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

@layer global {
  :root {
    font-size: clamp(1rem, 0.4rem + 0.8svw, 1.2rem);
  }

  body {
    font-family: var(--font-main);
    background-color: var(--background-color-1);
    color: var(--foreground-color-2);
  }

  a:any-link {
    color: var(--brand-color);
  }

  h1 {
    font-family: var(--font-heading);
    font-size: 2.2rem;
  }

  h2 {
    font-size: 1.125rem;
  }

  @media (min-width: 768px) {
    h1 {
      font-size: 3rem;
    }

    h2 {
      font-size: 2rem;
    }
  }
}

8.2.4 レイアウト層¶

多くのサイトではいくつかの異なるページ レイアウトがあります. たとえばホームページのレイアウトは記事とは異なる場合があり, 記事のレイアウトは検索結果ページとも異なります. レイアウト レイヤー上でこれらのそれぞれについて一般的なページ構造を定義できます.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

@layer layout {
  #homepage {
    display: grid;
    grid-template-areas:
        "header header"
        "main sidebar"
        "footer footer";
    grid-template-columns: 1fr 300px;
    gap: 1rem;
  }

  #homepage > header,
  #homepage > footer {
    grid-column: span 2;
  }

  #article > main {
    max-inline-size: 1000px;
    margin-inline: auto;
  }
}

これまではセレクターの特異性が高いため, このようなセレクターでIDを使用することは通常避けてきました. しかしカスケード レイヤーの場合は心配ありません. 次のレイヤーに追加するスタイルは, レイヤーの優先順位によって必要に応じてこれらのルールをオーバーライドできます. IDの代わりにクラス名を使用したい場合, 私が好んで使用する一般的な規則は, クラス名にプレフィックスl-を付けることです.

8.2.5 モジュール層¶

このような再利用可能なモジュールからサイト構築は, それ自体が大きなテーマです. これは次の章で詳しく見ていきます.

8.2.6 ユーティリティ層¶

8.2.7 追加のレイヤー¶

さまざまなモジュールの状態やステータスに応じて, ページに動的に追加またはページから削除されるスタイル用です. これには読み込み状態やドロップダウン メニューの開いた状態と閉じた状態などが含まれます.

8.3 :is()および:where()疑似クラス¶

大きなセレクターをより簡潔に記述できます.

以下の指定は等価.

1
2
3
4
5
6
7
8

.contact-form input,
.contact-form textarea,
.contact-form select,
.contact-form button {
  padding: 5px 10px;
  border: 1px solid var(--brand-color);
  border-radius: 5px;
}

1
2
3
4
5

.contact-form :is(input, textarea, select, button) {
  padding: 5px 10px;
  border: 1px solid var(--brand-color);
  border-radius: 5px;
}

正式に言えば:is()擬似クラスは一連のセレクターを引数として受け取り, 指定されたセレクターのいずれかに一致する要素と一致する関数です.

8.3.1 より寛容なセレクター¶

8.3.2 特異性の操作¶

:where()疑似クラスは機能的には:is()と同じで, 違いが一つあります. :where()の特異性は常にゼロです. つまり:where()は特異性の高いセレクターの特異性を下げるために使用できます.

8.4 ネスティング¶

8.4.1 ネストセレクターの使用¶

&をネストセレクターと呼ぶ.

1
2
3
4
5
6

.modal {
  display: none;
}
.modal.is-open {
  display: block;
}

1
2
3
4
5
6
7

.modal {
  display: none;

  &.is-open {
    display: block;
  }
}

ここで&がないと.modal.is-openではなく, スペースが入る.modal .is-openとして解釈されてしまう.

警告：Sassと違ってネストセレクターを使用して部分クラス名をマージできません.

&セレクターの順序を変更するにはネストされたセレクターの後に配置します.

1
2
3
4
5
6
7
8
9

.card {
  padding: 1rem;
  border-radius: 0.5rem;
  background-color: #fff;

  .homepage & {
    background-color: #ccc;
  }
}

8.4.2 ネストセレクターの微妙な違いを理解する¶

親セレクター参照のために&を使うと, 親セレクターを:is()疑似クラス関数で親セレクターをラップする形で脱糖(desugar)される.

8.4.3 メディアクエリとその他のアットルールのネスト¶

ネストされていない宣言は常にネストされたブロックの前に配置します¶

8.5 概要¶

• カスケード レイヤーはCSSの優先順位を明示的に制御します. レイヤーを使用すると, セレクターの指定性とソースの順序を単独で使用する場合に比べてどのスタイルを優先するかを操作するためのより合理的な手段が提供されます.
• これら6つのレイヤー(リセット・テーマ・グローバル・レイアウト・モジュール・ユーティリティ)をスタイルシートを整理するための便利なテンプレートとして使用します. プロジェクトの特定のニーズに基づいて必要に応じてこれを調整してください。
• :is()擬似クラスを使用すると, 指定されたセレクターのリストから選択できます. これは反復的で面倒なセレクターを短縮するのに役立ちます.
• :where()疑似クラスは常に特異性がゼロです. 他のスタイルをオーバーライドしないようにセレクターの特異性を抑える必要がある場合にこれを使用します.
• ネストすると親セレクター ブロック内に子孫セレクターまたは at-rule を配置できます.

9 モジュラー CSS とスコープ¶

• CSSを再利用可能なモジュールに整理する
• セレクターの特異性のエスカレーションの防止
• CSSの一般的な命名規則
• @scopeを使用してカスケードをより適切に制御する
• パターン ライブラリを使用してモジュールを文書化する

9.1 モジュールの定義¶

モジュラーCSSは ページをコンポーネント部分への分割を意味します. これらの部分は複数のコンテキストで再利用可能である必要があり, 相互に直接依存すべきではありません. 最終的な目標はCSSの一部を変更しても, 別の部分に予期しない影響が生じないようにすること.

9.1.1 モジュールはグローバル スタイルに依存する¶

9.1.2 単純なモジュール¶

9.1.3 モジュールのバリエーション¶

BEM クラス名の規則：二重ハイフンと二重アンダースコアのクラス名は, BEMと呼ばれる方法論の一部である一般的な規則です. BEMはBlock-Element-Modifierの頭字語です.

ヒント：モジュールのすべてのCSS(修飾子クラスも含む)は常に同じ場所にまとめて保管してください. これでスタイルシートは一連のモジュールで構成されます.

ページ内の位置に基づいてモジュールを変更するために子孫セレクターを使用しないでください. この一つのルールへの従属が, スタイルシートが保守不可能なコードの狂気へと陥ることを防ぐ最善の方法です.

9.1.4 複数の要素を含むモジュール¶

9.2 より大きな構造に構成されるモジュール¶

モジュールはそれぞれ一つのことを担当する必要があります. メッセージ モジュールはメッセージを目立つようにする役割を果たします. メディア モジュールはテキストの横に画像を配置する役割を果たします. その目的を簡潔に要約できる必要があります. 一部のモジュールはレイアウト用で, その他はスタイルを目的としています. モジュールが複数のことを実行しようとする場合, それをより小さなモジュールへの分割を検討する必要があります.

9.2.1 モジュール間での複数の責任の分割¶

場合によってはモジュールが自然に大きくなることがあります. 分割が難しい場合, 具体的に分割する必要があるまで分割しないでください.

9.2.2 モジュールの名前付け¶

適切なモジュール名の選択には熟考が必要です. モジュールを開発するときに一時的な名前を入力できますが, 完成したと考える前にその名前に注意を払っていることを確認してください. これをうまく実行するのはおそらくモジュール式CSSを書く上で最も難しい部分です.

モジュールは多用途である必要があります. その名前はシンプルで覚えやすいものが理想的です. サイトのさらに多くのページをデザインするとき, 任意の数の目的でモジュールを再利用できます.

すべてのモジュールの名前に二つの単語を使用して, 一般的になりすぎないように強制する人もいます. まったく新しいタイル モジュールがいつ必要になるかはわかりません. 既存のタイル モジュールの名前をより正確に指定すると, 二つの混同がなく, 新しいタイル モジュールにもう少し自由に名前を付けることができます.

モジュールのバリアント クラスに名前を付けるときは同様の原則を適用する必要があります. たとえばボタン モジュールがある場合, 赤と青のバリアントをbutton--redやbutton--blueのようにサブクラス化しないでください. サイトのデザインは将来変更される可能性が高く, これらの色も変更されるかどうかはわかりません. button--dangerやbutton--successのようなより意味のある名前を見つけてみてください.

9.3 CSS スコープ¶

9.3.1 スコープの近接性¶

9.3.2 スコープ制限¶

Shadow DOMと比較したスコープ：Shadow DOMはWebコンポーネントをWebページの外側の部分から分離する手段としてWebコンポーネントを定義するときに使用されます. Shadow DOMはスタイルのスコープを提供する方法として提供されることがありますが, これは特定の状況でのみ役立つと思います. Shadow DOMは主にJavaScript主導の機能であるため, 本書の範囲外です. ただしShadow DOMのユーザーがスコープについて説明するときによく質問されるため, スコープとの違いに注意してください.

すべてのモジュールがスコープされている場合, 考慮する必要がある名前の競合はモジュールのルート要素のクラス名だけです. 何らかの方法でこれらのクラスを特殊なケースとして区別することをお勧めします. 一つのオプションはすべてのモジュール クラス名にm-のような共通のプレフィックスを付けることです。 結果としてm-mediaやm-dropdownのような一意のクラス名が得られます. クラス名ではなく<div data-scope="dropdown">のようなカスタム属性を使用することもできます. 後者のアプローチを使用する場合は属性セレクターを使用してスコープを定義できます. 例えば@scope ([data-scope="dropdown"]) to ([data-scope]).

9.3.3 暗黙的なスコープ¶

9.3.4 スコープとレイヤー¶

9.4 パターンライブラリ¶

9.4.1 CSS First ワークフローの使用¶

開発者はスタイルを設定しやすいHTMLをどのように記述したらよいかよく尋ねます. これは間違った質問だと思います. 代わりに任意の数のページで再利用できるスタイルをどのように記述できるかを考える必要があります. 最初にCSSを記述する必要があり, 適切に構造化されたHTMLが続きます. CSSのモジュール編成がこれを実現する手段です. CSSのモジュールはページ上で機能するために必要なHTMLの構造を決定します.

9.4.2 リファクタリングと破壊的な変更¶

場合によっては古いバージョンとの互換性がなくなるような方法でモジュールに変更を加える必要がある場合があります. 多くの場合,最善の行動はモジュールを非推奨にし(パターン ライブラリでそのことを示す), 必要な新しい機能用にまったく新しいモジュールの作成です. これで古いモジュールは使用されている場所で引き続き動作する一方, 両方がサポートされている間に新しいモジュールへの移行を開始できます. semverによるCSSのバージョン管理が有効です.

実際にはこのバージョン管理にはいくつかの方法があります. スタイルを使用するプロジェクトの性質によって異なります. たとえばCSSをNodeJSモジュールまたはRuby Gemの一部としてパッケージ化する場合, これらのシステムに組み込まれているバージョン管理を使用します. CSSをサーバー上で静的にホストしている場合, http://example.com/css/1.4.2/styles.cssのようにURLにバージョン番号を含めて, 複数のバージョンを同時にホストします.

9.5 概要¶

• モジュールはページ内のコンテキストに依存しない, 再利用可能な小さなスタイル部分です. モジュールのスタイルはカプセル化のプログラミング原則に従って, スタイルシート内の一か所にグループ化する必要があります. モジュラーCSSが別のモジュールに到達してその外観を変更することはありません.
• バリアント クラスを使用すると同じモジュールの複数のバージョンを提供できます.
• 大きな構造は小さなモジュールに分割する必要があります. 多数のモジュールをつなぎ合わせてページを組み立てます。
• 二重ハイフンや二重アンダースコアなどの命名規則を使用すると, モジュールの構造を一目で理解しやすくできます.
• @scopeはスタイルのセットをページの特定の部分に制限する新しい機能です. これはモジュール スタイルを目的のモジュールにスコープしておくための完璧なツールです. 内部スコープ制限を指定すると, これらのスタイルが子孫スコープをターゲットにできなくなります. この機能に対する新しいブラウザーのサポートに注目してください.
• 大規模なプロジェクトではパターン ライブラリを構築してモジュールを文書化し, インベントリを作成できます. 新しいページを組み立てるときに使用できるスタイルの参考としてこれを使用してください.

10 コンテナクエリ¶

• コンテナーの定義と@containerの使用
• コンテナのサイズに基づいてモジュールの応答性を高める
• コンテナ相対単位の使用
• スタイル クエリを使用してカスタム プロパティの値に基づいてスタイルを変更する

ページ上のどこでも使用できるモジュールの設計はレスポンシブ デザインのコンテキストでは難しい場合があります. サイドバーなどの狭い列にモジュールを配置したい場合がよくあります. ビューポート自体は大きいかもしれませんが, その特定のモジュールに利用できるスペースは大きくありません. だから定期的な@mediaクエリは, モジュールの応答性を高めるための実用的なアプローチであるとは限りません.

CSSの新機能であるコンテナ クエリは, より汎用性の高いオプションを提供します.

10.1 コンテナクエリの基本的な例¶

理論的にはメディア クエリを追加してこれに対処できます. これはモジュール設計の重要な原則の一つに違反しています. つまりモジュールが使用されるコンテキストを気にせずにモジュールを設計できる必要があります

これに対するより良いアプローチは, メディア クエリを完全に回避し, 代わりにコンテナ クエリを使用することです. このようなモジュールの場合ビューポートのサイズは関係ありません. 重要なのはモジュールを保持するコンテナのサイズです.

10.1.1 コンテナサイズクエリの使用¶

コンテナ サイズ クエリを使用するには次の二つの手順が必要です. コンテナを定義してからコンテナをクエリします. まずメディア モジュールを改善するための基本的な使用例を説明し, 次にコンテナを定義するときに使用できるいくつかの追加オプションを詳しく見ます.

CSSでは長い間コンテナという用語は祖先要素を指すために使用されてきました. 通常はページの領域を定義するために何らかのサイズ設定または背景色が与えられた要素です. これはコンテナー クエリのコンテキストでも依然として当てはまります. ただしコンテナ サイズのクエリの場合はcontainer-typeプロパティ, オプションでcontainer-name.

10.2 コンテナを詳しく見る¶

10.2.1 コンテナの種類¶

10.2.2 コンテナ名¶

10.2.3 コンテナとモジュール式 CSS¶

モジュールを操作する場合, ほとんどの場合, メディア クエリよりもコンテナ クエリの方が適切な選択肢です. ページ全体でコンテナを一貫して定義している限り, 通常は代わりにすべてのモジュールにコンテナを使用できます.

10.3 コンテナ相対単位¶

10.4 コンテナスタイルのクエリ¶

10.4.1 コンテナからモジュールを切り離す¶

10.4.2 コードの重複を減らす¶

場合によっては, いくつかの事態のいずれかが発生したときに適用したいスタイルがある場合があります. これが発生する一般的な状況は, ライト モードとダーク モードを切り替えることができるサイトです. 理想的にはprefers-color-schemeメディア クエリを使用して, ページを最初に正しいモードで表示すると同時に, ユーザーがいくつかのJavaScript制御入力を介してモードを切り替えることもできます.

10.5 概要¶

• コンテナ サイズ クエリを使用すると, スタイルがコンテナのサイズに応答できるようになります. これは多くの場合, 従来のメディア クエリよりも実用的なアプローチです.
• コンテナ タイプを要素に適用すると, コンテナが確立されます. @containerを利用してコンテナのサイズをクエリし, それに応じて子要素のスタイルを設定します.
• インライン サイズまたはサイズ タイプのコンテナ内の要素は, 測定されたディメンションのサイズに影響を与えない場合があります.
• コンテナ相対単位は, コンテナのインライン サイズまたはブロック サイズのパーセンテージとしてサイズを決定します. これらは概念的にはビューポートの相対単位と非常によく似ています.
• コンテナ クエリのstyle()関数を使用すると, コンテナのカスタム プロパティの値に基づいて条件付きスタイルを適用できます. これは新しいブラウザーのサポートによる新機能です.

パート 4 視覚的な強化¶

今度はそれらを美しく見せる時が来ました. ユーザーはプロフェッショナルな外観のアプリケーションを信頼する傾向があり, サイトが見た目に美しい場合は, より多くの時間をそのサイトの使用に費やす傾向がある可能性があります. この四つの章では, これまでに学んだことをすべてまとめて検討し, 設計に関していくつかの重要な考慮事項を指摘します. これらはサイトの外観に大きな影響を与える可能性のある小さな詳細です.

11 色とコントラスト¶

• デザイナーのモックアップをHTMLとCSSに変換する
• コントラストを使用してページの適切な部分に注目を集める
• 色の選択と操作
• 色空間とさまざまなCSSの色表記について理解する
• OKLCHカラーの詳細
• 色に関するアクセシビリティの問題

2024-08 F# in Action¶

• GitHub

もっと前から知ってはいたが, 改めて目次を見たら後半の内容が特に気になったため購入. 後半が本当によさそうで, ざっと読んだら再読・熟読したい.

9.3

r "nuget:FSToolkit.ErrorHandling, 2.13.0"¶

open FsToolkit.ErrorHandling

let myMaybeData = option { let! numberOne = tryParseNumber "1" let! numberTwo = tryParseNumber "2" let! numberThree = tryParseNumber "3" return calc numberOne numberTwo numberThree }

MS Learn scisharpある?

10.1 traverse 10.2 DTO処理 生の JSON からリッチな F# ドメインへの魔法のマッピングを行うためにシリアル化ライブラリだけに頼らないでください。プリミティブ値のみを使用する最も単純なドメイン モデルがない限り、努力する価値はありません。 10.3.1 JSON型プロバイダーの操作 リスト10.4

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#r "nuget:FSharp.Data"
open FSharp.Data

[<Literal>]
let SampleJson = """{
    "Brand": "Ibanez",
    "Strings": "7",
    "Pickups": [ "H", "S", "H" ] }"""
type GuitarJson = JsonProvider<SampleJson>
let sample = GuitarJson.GetSample()
let description = $"{sample.Brand} has {sample.Strings} strings."

1
2

type GuitarJson =
    JsonProvider<const(__SOURCE_DIRECTORY__ + "/sample-guitars.json")>

1
2
3
4
5
6

type ManyGuitarsOverHttp =
    JsonProvider<"https://raw.githubusercontent.com/
 isaacabraham/fsharp-in-action/main/
 sample-guitars.json">
let inventory = ManyGuitarsOverHttp.GetSamples()
printfn $"You have {inventory.Length} guitars in stock."

リスト10.5

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#r "nuget:FSharp.Data"
open FSharp.Data

type LondonBoroughs =
    HtmlProvider<"https://en.wikipedia.org/wiki/
 List_of_London_boroughs">

let boroughs =
    LondonBoroughs.GetSample().Tables.
 ``List of boroughs and local authoritiesEdit``

boroughs.Rows |> Array.map (fun row -> row.Borough)

SQL データベースから生の型を生成する Facil などの F# 固有のライブラリがあります。 Microsoft SQL Server を操作するためのオプションは、DataReader、Dapper、Facil など多数あります。それぞれに長所と短所があり、どのオプションを使用する場合でも、より豊富なドメインにマッピングする前に、単純な型のデータを F# に取り込むという原則に従ってください。

asyncとtask

私のアドバイスとしては、タスクから始めることです。 特にC#でタスクを既に知っている場合は, タスクの方が.NETの世界でより人気があり非常にうまく機能するためです. ただし2つの違いを直接理解し, 必要な動作に基づいてどちらが適切かを柔軟に選択できるようにするためだけでも, 非同期ワークフローを調査して実践的な経験を積む必要があります.

12はまた読もう.

13.

• Validus
• FsToolkit.ErrorHandling
• taskresult
• Expecto

2024-08 Learn Rust in a Month of Lunches¶

• Livebook
• Rust playground

Chapter2¶

• URL

Chapter2は参照・所有権があったため非常に時間がかかる. 覚悟を決めて読むこと.

• スタック・ヒープ・ポインタ・参照を理解する
• Rustでよく見かけるポインタは参照で, メモリセーフなポインタとみなせる.
  • 所有されているメモリへの参照ポイント.
  • 安全でないランダムなメモリ位置ではない.
• 参照は別の値のメモリを指す
• 参照は値を借用するが所有はしない
• 参照の前に&がつく.

1
2

let my_variable = 8
let my_reference = &my_variable

「文字列」に関するStringと&strの違い.

• &strは単純な文字列. 文字列スライスとも言う.
  • データへのポインタと長さの組み合わせ.
• StringはStringヒープ上のデータを持つポインタ.
• 最大の違いはStringはデータを所有する一方, &strはスライス(データのビュー)
• Stringは簡単に拡大・縮小・変更できる.

constとstatic

• const: 変更されず, コンパイル時に作成される値.
  • グローバル変数ではふつうこちらを使う.
• static:メモリ位置が固定. コンパイル時に作成されない可能性あり.

参照を使用してデータを変更する場合は可変参照を利用する. &mutを使えばよい.

&が参照で*は逆参照.

1. 不変参照: 不変参照は必要な数だけ持てる. データを表示するだけだから.
2. 可変参照: 可変参照は一つだけ持てる. 不変参照と可変参照を一緒に持てない. 可変参照はデータを変更できるため, 他の参照がデータを読み取るときにデータを変更すると問題が起き得る.

Rust's simplest types are known as Copy types. They are all on the stack. Rustの最も単純な型はCopytypesと呼ばれる. これらはすべてスタック上にあってコンパイラはそのサイズを認識している. 移動セマンティクスとコピーセマンティクス.

• 不変参照: 画面に表示されている内容を何度でも問題なく同僚に見せられる.
• 可変参照: 同僚が座って少しの間あなたのコンピュータを使いたい場合, 十分な理由があるはず. 二人の同僚が同時にあなたのコンピュータの前に座って入力できない.
• 所有権の譲渡: 同僚があなたのコンピューターを所有したい場合, 返還を求められないため正当な理由が必要. 晴れて許可が得られれば同僚はコンピューターを変更可能と宣言して自分の好きなように使用する.

まとめ

• constとstaticプログラムの存続期間中はどこでも使える.
• デフォルトでデータの所有権を取得する. 借用する場合は参照を利用.
• 文字列にも所有権の概念がある. 所有型のStringと借用文字列の&str.
• Copy型は単純で所有権について心配不要.
• 型は「移動セマンティクス」ではなく「コピーセマンティクス」を利用する.

Chapter3 より複雑な型¶

• URL

Chapter2は参照・所有権があったため非常に時間がかかったが, この章はさくっと読める.

• 配列 - 同じ型のシンプルで高速な不変のコレクション
• ベクトル - 配列に似ていますが、拡張可能で、より多くの機能があります
• タプル（さまざまなタイプのグループ化）
• 制御フロー - 状況に応じてコードの実行方法を変える

配列はベクターよりも単純な型で, メモリを割り当てることができない小さな組み込みデバイスなどでも使用できます.

• 配列には同じ型のみを含める必要がある.
• 配列のサイズは変えられない.

1
2
3
4

fn main() {
    let my_array = ["a"; 5];
    println!("{:?}", my_array);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

fn main() {
    let array_of_ten = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];

    let two_to_five = &array_of_ten[2..5];
    let start_at_one = &array_of_ten[1..];
    let end_at_five = &array_of_ten[..5];
    let everything = &array_of_ten[..];

    println!("Two to five: {two_to_five:?},
Start at one: {start_at_one:?},
End at five: {end_at_five:?},
Everything: {everything:?}");
}

// Two to five: [2, 3, 4],
// Start at one: [1, 2, 3, 4, 5, 6, 7, 8, 9],
// End at five: [0, 1, 2, 3, 4],
// Everything: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

3.1.2 ベクトル 配列に加えてベクターもあります. この二つつの違いは&strとStringの違いに似ています. 配列はより単純で柔軟性と機能性が低く高速である可能性があります. 一方ベクターはサイズを変更できるため操作が簡単です. (配列は動的にサイズが変更されないため, コンパイラは常にそのサイズを認識している. 前の例では配列を使用するために参照は不要だった.)

Vecを作成するもう一つの簡単な方法はvec!マクロ.

1
2
3

fn main() {
    let mut my_vec = vec![8, 10, 10];
}

ベクトルの配列化.into()

1
2
3
4

fn main() {
    let my_vec: Vec<u8> = [1, 2, 3].into();
    let my_vec2: Vec<_> = [9, 0, 10].into();
}

3.1.3 タプル.

Rustでは空のタプルはユニット型と呼ばれる.

3.2 制御フロー

1
2
3
4
5
6

fn main() {
    let my_number = 5;
    if my_number == 7 {
        println!("It's seven");
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

fn main() {
    let my_number = 5;
    if my_number == 7 {
        println!("It's seven");
    } else if my_number == 6 {
        println!("It's six")
    } else {
        println!("It's a different number")
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

fn main() {
    let my_number = 5;
    if my_number % 2 == 1 && my_number > 0 {
        println!("It's a positive odd number");
    } else if my_number == 6 {
        println!("It's six")
    } else {
        println!("It's a different number")
    }
}

1
2
3
4
5
6
7
8
9

fn main() {
    let my_number: u8 = 5;
    match my_number {
        0 => println!("it's zero"),
        1 => println!("it's one"),
        2 => println!("it's two"),
        _ => println!("It's some other number"),
    }
}

ifによるマッチガード.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fn main() {
    let children = 5;
    let married = true;

    match (children, married) {
        (children, married) if married == false =>
    println!("Not married with {children} kids"),
        (children, married) if children == 0 && married == true => {
            println!("Married but no children")
        }
        _ => println!("Married? {married}. Number of children: {children}."),
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fn main() {
    let children = 5;
    let married = true;

    match (children, married) {
        (children, married) if !married =>
         println!("Not married with {children} kids"),
        (children, married) if children == 0 && married =>
         println!("Married but no children")
        _ => println!("Married? {married}.
        Number of children: {children}."),
    }
}

3.2.3ループ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

fn main() {
    let mut counter = 0;
    loop {
        counter +=1;
        println!("The counter is now: {counter}");
        if counter == 5 {
            break;
        }
    }
}

ループへの命名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

fn main() {
    let mut counter = 0;
    let mut counter2 = 0;
    println!("Now entering the first loop.");

    'first_loop: loop {
        counter += 1;
        println!("The counter is now: {}", counter);
        if counter > 5 {
            println!("Now entering the second loop.");

            'second_loop: loop {
                println!("The second counter is now: {}", counter2);
                counter2 += 1;
                if counter2 == 3 {
                    break 'first_loop;
                }
            }
        }
    }
}

forによるループ.

1
2
3
4
5
6
7
8
9

fn main() {
    for number in 0..3 {
        println!("The number is: {}", number);
    }

    for number in 0..=3 {
        println!("The next number is: {}", number);
    }
}

まとめ

• 配列は非常に高速である一方, サイズと型は固定.
• ベクトルはStringに似ている.
• 所有型で柔軟.
• タプルは数値でアクセスできる項目を保持する. ただしインデックス付きコレクションではなく独自の新しい型のように動作.
• matchが使える.コードが非常に読みやすくなります。
• Rustではmatchでステートメント内のすべてが一致するか確認.
• 構造化分解は強力. ほぼあらゆる方法で型を分解できる.
• rangeは'何かがいつ始まり, いつ終わるかを人間が判読できる形で表現するのに適している.
• ループ内にループがある場合, ループに名前を付けてどのループから抜け出すかをコードに指示できる.

Chapter4 独自の型を構築する¶

• URL

はじめに¶

• 構造体は値をグループ化して独自の型を構築するために使用できます
• 列挙型は構造体に似た構文ですが、グループ化ではなく選択に使用されます。
• 構造体と列挙型にメソッドを与える型の実装
• 構造化解除と型の分解について
• 参照とドット演算子

Rustで独自の型を構築する主な方法, つまり構造体と列挙型を見る. これらの型にアタッチされて呼び出される関数, つまりメソッドの実装方法も学ぶ. これらのメソッドはキーワードselfをよく利用する.

4.1 構造体と列挙型の概要¶

構造体は列挙型を含められ, 列挙型は構造体を含められるためこれらは一緒に機能する.

• グループ化するものが多数ある場合は構造体.
• 選択肢が多数ある中の一つを選ぶ必要がある場合は列挙型.

構造体の名前はUpperCamelCase.

タプル構造体, または名前のない構造体.

1
2
3
4
5
6

struct ColorRgb(u8, u8, u8);

fn main() {
    let my_color = ColorRgb(50, 0, 50);
    println!("The second part of the color is: {}", my_color.1);
}

構造体は多くのものをまとめて扱うための概念で, 列挙型は多くの選択肢を扱うための概念.

メソッドと関連関数

• メソッド: &self, &mut selfまたはselfを取る. 通常のメソッドでは.を利用.
• 関連関数: selfを取らない. 関連関数は型名と関数名の間に::を入力して別の方法で呼び出す. String::from()やVec::new()が例.

Chapter5 Generics, option, and result¶

• URL
• ジェネリクス: 複数の型を使用する場合
• Option: 操作によって値が生成されるかもしれない
• Result: 操作に対して成功・失敗がある

Chapter6 More collections, more error handling¶

• URL
• Other collections—more complex and interesting ones this time
• The question mark operator—just type ? to handle errors
• When panic and unwrap are good

HashMap, BTreeMap. .get()を使うとOptionで返してくれる. HashSet. BinaryHeap.

Chapter7 Traits: Making different types do the same thing¶

• URL

トレイトやクラスやインターフェースなどではなくあくまでトレイト. 多言語の余計な常識を使って判断してはいけない.

Debug, Copy, Cloneなどがtrait. #[derive(Debug)]などで指定する.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

struct Dog {
    name: String,
}

struct Parrot {
    name: String,
}

trait DogLike {
    fn bark(&self) {
        println!("Woof woof!");
    }
    fn run(&self) {
        println!("The dog is running!");
    }
}

impl DogLike for Dog {}
impl DogLike for Parrot {}

fn main() {
    let rover = Dog {
        name: "Rover".to_string(),
    };

    let brian = Parrot {
        name: "Brian".to_string(),
    };

    rover.bark();
    rover.run();
    brian.bark();
}

1
2
3

Woof woof!
The dog is running!
Woof woof!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

struct Animal {
    name: String,
}

trait DogLike {
    fn bark(&self);
    fn run(&self);
}

impl DogLike for Animal {
    fn bark(&self) {
        println!("{}, stop barking!!", self.name);
    }
    fn run(&self) {
        println!("{} is running!", self.name);
    }
}

fn main() {
    let rover = Animal {
        name: "Rover".to_string(),
    };

    rover.bark();
    rover.run();
}

Displayトレイトのドキュメント

Fromトレイト.

orphan rule

• 自分のトレイトを他の人のタイプに実装できる.
• 他の人のトレイトを自分のタイプに実装できる.
• 他の人のトレイトを他の人のタイプに実装できない.

newtypeイディオム. orphan rule孤立ルールを回避する方法はあるか? 他の人の型をタプル構造体にラップして新しい型を作ると簡単.

AsRefトレイト.

Chapter8 イテレータとクロージャ¶

• URL
• メソッドチェーンを使用してメソッドを次から次へと呼び出す
• コレクションを操作する最も便利な方法であるイテレータを使用する
• クロージャは名前が不要でスコープ内の変数をキャプチャできる関数.

いわゆる関数型スタイル.

1
2
3
4

fn main() {
    let new_vec = (1..).take(10).collect::<Vec<i32>>();
    println!("{new_vec:?}");
}

1
2
3
4
5

fn main() {
    let my_vec = vec![0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
    let new_vec = my_vec.into_iter().skip(3).take(4).collect::<Vec<i32>>();
    println!("{new_vec:?}");
}

イテレータの種類.

• .iter(): 参照の反復子
• .iter_mut(): 可変参照のイテレータ
• .into_iter(): 非参照の値の反復子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

fn main() {
    let vector1 = vec![1, 2, 3];
    let vector1_a = vector1
        .iter()
        .map(|x| x + 1)
        .collect::<Vec<i32>>();
    let vector1_b = vector1
        .into_iter()
        .map(|x| x * 10)
        .collect::<Vec<i32>>();
    let mut vector2 = vec![10, 20, 30];
    vector2.iter_mut().for_each(|x| *x +=100);

    println!("{:?}", vector1_a);
    println!("{:?}", vector1_b);
    println!("{:?}", vector2);
}

クロージャ

1
2
3
4

fn main() {
    let my_closure = || println!("This is a closure");
    my_closure();
}

1
2
3
4
5

fn main() {
    let my_closure = |x: i32| println!("{x}");
    my_closure(5);
    my_closure(5+5);
}

1
2
3
4
5
6

fn main() {
    let number_one = 6;
    let number_two = 10;
    let my_closure = || println!("{}", number_one + number_two);
    my_closure();
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fn main() {
    let my_vec = vec![8, 9, 10];

    let fourth = my_vec.get(3).unwrap_or_else(|| {
        if let Some(val) = my_vec.get(2) {
            val
        } else {
            &0
        }
    });

    println!("{fourth}");
}

1
2
3
4
5
6
7
8

fn main() {
    let char_vec = vec!['z', 'y', 'x'];

    char_vec
        .iter()
        .enumerate()
        .for_each(|(index, c)| println!("Index {index} is: {c}"));
}

Chapter9 イテレータとクロージャについてもう一度！¶

• フィルタリングを使用してイテレータに必要なものを保持する
• イテレータの反転・圧縮・循環
• イテレータで必要な値だけを取得する
• イテレータ内の何かまたはすべてが条件に一致するかどうかを判断する
• dbg!マクロを使用してコードがどの時点で何を実行しているかを確認する
• イテレーターメソッド集
  • Trait std::iter::Iterator
  • itertools crate

.filter(), .filter_map()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fn main() {
    let months = vec!["January", "February", "March", "April", "May",
    "June", "July", "August", "September", "October", "November",
    "December"];

    let filtered_months = months
        .into_iter()
        .filter(|month| month.len() < 5)
        .filter(|month| month.contains("u"))
        .collect::<Vec<&str>>();

    println!("{:?}", filtered_months);
}

ok(), ok_or(), ok_or_else(). parse() unwrap(), unwrap_or(), unwrap_or_else(), map(), and_then(), flatten() any(), all(). find(), position(), cycle(), zip(), fold(), for_each(), take_while(), cloned(), by_ref(), chunks(), match_indices(), enumerate()

iter()は参照を提供する.

Chapter10 寿命と内部可変性¶

• &strの種類
• ライフタイムアノテーションを使用してコンパイラーが参照の存続期間を認識できるようにする
• &mutを使用せずに安全な可変性を提供する内部可変性の使用

ライフタイムは変数をいつ削除できるか参照がどれくらい持続するかを知るためにコンパイラが利用する. 可変参照なしに安全に値を変更する方法も議論する.

10.1 &strの種類

• 文字列リテラル: &'static str
• 借用されたstr: これが'staticライフタイムのない, 普通の&str.

borrowed strの例

1
2
3
4
5
6
7
8

fn prints_str(my_str: &str) {
    println!("{my_str}");
}

fn main() {
    let my_string = String::from("I am a string");
    prints_str(&my_string);
}

10.2 ライフタイムアノテーション

ライフタイムは「変数または参照の存続期間」を意味する.

10.2.1 関数の有効期間

関数には明確な開始と終了があるため, 関数でライフタイムを扱うのはそれほど難しくない.

次は動作しない関数の例.

1
2
3
4

fn returns_reference() -> &str {
    let my_string = String::from("I am a string");
    &my_string
}

次のコードは動くがライフタイムに対するワーニングが出る.

1
2
3
4
5
6
7
8
9

fn returns_str() -> &str {
    let my_string = String::from("I am a string");
    "I am a str"
}

fn main() {
    let my_str = returns_str();
    println!("{my_str}");
}

次のコードはワーニングなし.

1
2
3
4
5
6
7
8

fn returns_str() -> &'static str {
    "I am a str"
}

fn main() {
    let my_str = returns_str();
    println!("{my_str}");
}

コンパイラは賢いためふつうは有効期間を理解できます. コンパイラが独自に決定できない場合にだけ参照の有効期間を記述する必要がある.

10.2.2 型のライフタイムアノテーション

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#[derive(Debug)]
struct City {
    name: &'static str,
    date_founded: u32,
}

fn main() {
    let city_names = vec!["Ichinomiya".to_string(),
    "Kurume".to_string()];

    let my_city = City {
        name: &city_names[0],
        date_founded: 1921,
    };

    println!("{} was founded in {}", my_city.name, my_city.date_founded);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#[derive(Debug)]
struct City<'a> {
    name: &'a str,
    date_founded: u32,
}

fn main() {
    let city_names = vec!["Ichinomiya".to_string(), "Kurume".to_string()];

    let my_city = City {
        name: &city_names[0],
        date_founded: 1921,
    };

    println!("{} was founded in {}", my_city.name, my_city.date_founded);
}

10.2.3 匿名の存続期間

<'_>: 匿名ライフタイム.

10.3.2 RefCell

• 不変の借用がたくさんあるのは問題ない.
• 変更可能な借用は一つだけで十分.
• 可変借用と不変借用を同時使用は問題ない.

10.3.3 ミューテックス

Mutexは「相互排他」を意味し, 「一度に一つだけ」を意味する.

10.3.4 RwLock

Chapter11 複数のスレッドなど¶

• todo!マクロ：コンパイラをしばらく静かにするマクロ
• 新しい型ではなく別の名前を作成するための型エイリアス
• Cow列挙型. データを自由に借用するか所有するかを選択できます.
• Rcは一意の所有権ではなく共有所有権を許可します
• 複数のスレッドを使用して多くのことを同時に実行する

11.1 関数内でのインポートと名前変更

11.2 todo!マクロ

プロトタイピング時に便利.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

struct Book;

enum BookType {
    HardCover,
    SoftCover,
}

fn get_book(book: &Book) -> Option<String> {
    todo!();
}

fn delete_book(book: &Book) -> Result<(), String> {
    todo!();
}

fn check_book_type(book_type: &BookType) {
    match book_type {
        BookType::HardCover => println!("It's hardcover"),
        BookType::SoftCover => println!("It's softcover"),
    }
}

fn main() {
    let book_type = BookType::HardCover;
    check_book_type(&book_type);
}

11.3 型のエイリアス

11.4 Cow

Cowは非常に便利な列挙型です. これは「書き込み時のクローン」を意味し, Stringを所有する必要がない場合は&strを返し, またはもし必要ならStringを返しす. 借りたいけれど所有したいと思う他のタイプでも同じようにできる.

1
2
3
4

enum Cow {
    Borrowed,
    Owned
}

1
2
3
4

enum Cow<B> {
    Borrowed(B),
    Owned(B),
}

1
2
3
4
5
6
7

enum Cow<'a, B>
where
    B: 'a + ToOwned + ?Sized,
 {
    Borrowed(&'a B),
    Owned(<B as ToOwned>::Owned),
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

use std::borrow::Cow;

struct User {
    name: Cow<'static, str>,
}

fn main() {
    let user_name = "User1";
    let other_user_name = "User10".to_string();

    let user1 = User {
        name: user_name.into(),
    };

    let user2 = User {
        name: other_user_name.into(),
    };

    for name in [user1.name, user2.name] {
        match name {
            Cow::Borrowed(n) => {
                println!("Borrowed name, didn't need an allocation:\n  {n}")
            }
            Cow::Owned(n) => {
                println!("Owned name because we needed an allocation:\n  {n}")
            }
        }
    }
}

11.5 Rc

参照カウンター.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

use std::rc::Rc;

#[derive(Debug)]
struct City {
    name: Rc<String>,
    population: u32,
    city_history: Rc<String>,
}

#[derive(Debug)]
struct CityData {
    names: Vec<Rc<String>>,
    histories: Vec<Rc<String>>,
}

fn main() {
    let calgary_name = Rc::new("Calgary".to_string());
    let calgary_history = Rc::new("Calgary began as a fort called Fort
    Calgary that...".to_string());

    let calgary = City {
        name: Rc::clone(&calgary_name),
        population: 1_200_000,
        city_history: Rc::clone(&calgary_history)
    };

    let canada_cities = CityData {
        names: vec![Rc::clone(&calgary_name)],
        histories: vec![Rc::clone(&calgary_history)],
    };

    println!("Calgary's history is: {}", calgary.city_history);
    println!("{}", Rc::strong_count(&calgary.city_history));
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

use std::rc::Rc;

fn takes_a_string(input: Rc<String>) {
    println!("It is: {input}")
}

fn main() {
    let user_name = Rc::new(String::from("User MacUserson"));

    takes_a_string(Rc::clone(&user_name));
    takes_a_string(Rc::clone(&user_name));
}

11.5.3 Rcによるライフタイムアノテーションの回避

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

use std::rc::Rc;

#[derive(Debug)]
struct City {
    name: Rc<String>,
    date_founded: u32,
}

#[derive(Debug)]
struct Country {
    cities: Vec<City>,
}

#[derive(Debug)]
struct World {
    countries: Vec<Country>,
}

impl World {}

fn main() {
    let city_names = vec![
        Rc::new("Ichinomiya".to_string()),
        Rc::new("Kurume".to_string()),
    ];

    let my_city = City {
        name: Rc::clone(&city_names[0]),
        date_founded: 1921,
    };

    println!("{} was founded in {}", my_city.name, my_city.date_founded);
}

11.6 マルチスレッド

11.6.1 スレッドの生成 11.6.2 JoinHandles を使用してスレッドの終了を待機する

エラーになるコード.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

fn main() {
    let mut join_handles = vec![];
    for num in 0..10 {
        let handle = std::thread::spawn(|| {
            println!("Inside thread number: {num}");
        });
        join_handles.push(handle);
    }
    for handle in join_handles {
        handle.join().unwrap();
    }
}

動くコードはクロージャーにmoveを追加.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

fn main() {
    let mut join_handles = vec![];
    for num in 0..10 {
        let handle = std::thread::spawn(move || {
            println!("Inside thread number: {num}");
        });
        join_handles.push(handle);
    }
    for handle in join_handles {
        handle.join().unwrap();
    }
}

11.6.3 クロージャーの種類

• FnOnce: 値による取得
• FnMut: 変更可能な参照を取得します
• Fn: 定期的に参照する

1
2
3
4
5
6
7
8
9

fn main() {
    let mut my_string = String::from("I will be changed in the closure");
    let mut my_closure = || {
        my_string.push_str(" now");
        println!("{my_string}");
    };
    my_closure();
    my_closure();
}

1
2
3
4
5
6
7
8
9

fn main() {
    let mut my_string = String::from("I will be changed in the closure");
    let mut my_closure = || {
        my_string.push_str(" now");
        println!("{my_string}");
    };
    my_closure();
    my_closure();
}

1
2
3
4
5
6
7
8

fn main() {
    let my_vec: Vec<i32> = vec![8, 9, 10];
    let my_closure = || {
        my_vec.into_iter().for_each(|item| println!("{item}"));
    };
    my_closure();
    // my_closure();
}

11.6.4 moveキーワードの使用

1
2
3
4
5
6
7

fn main() {
    let my_string = String::from("Can I go inside the thread?");
    let handle = std::thread::spawn(move || {
        println!("{my_string}");
    });
    handle.join().unwrap();
}

まとめ

• clone()の利用が多すぎると感じたらRc
• 開始する前にコードの概要をスケッチしたい場合はtodo!を利用する.
• Cowは所有値と借用値の両方を取得できる非常に便利な型.
• 新しい型を作る場合それに好きな特性を実装できる. 孤立ルールを回避する最も一般的な方法です. ただし型エイリアスは既存の型の新しい名前にすぎないため、型エイリアスを使用しても基本的な動作は変わりません。
• スレッドは独立しているため別のスレッドが時間までに終了しない可能性があります. スレッドが終了するのを待ちたい場合はJoinHandleから得られるspawn().
• スレッドが借用するデータよりも長く存続する可能性があるため, 複数のスレッドを使用する場合, コンパイラは特に厳格であるように見える. moveをうまく使う.

Chapter12 クロージャ、ジェネリック、スレッドの詳細¶

• 関数内のクロージャ
• ジェネリックスを使用する別の方法としてimpl Traitを使用する
• ArcとRcは似ているがArcはスレッドセーフ
• スコープ付きスレッド・スコープ内でのみ存在するスレッド
• チャネルを使用して(スレッド間でも)メッセージを送信

1
2
3

fn all<F>(&mut self, f: F) -> bool
where
    F: FnMut(Self::Item) -> bool,

1
2
3
4
5
6
7

fn map<B, F>(self, f: F) -> Map<Self, F>
    where
        Self: Sized,
        F: FnMut(Self::Item) -> B,
    {
        Map::new(self, f)
    }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

fn do_something<F>(f: F)
where
    F: FnOnce(),
{
    f();
}

fn main() {
    let some_vec = vec![9, 8, 10];
    do_something(|| {
        some_vec
            .into_iter()
            .for_each(|x| println!("The number is: {x}"));
    });
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

fn do_something<F>(f: F)
where
    F: Fn(),
{
    f();
}

fn main() {
    let some_vec = vec![9, 8, 10];
    do_something(|| {
        some_vec.iter().for_each(|x| println!("The number is: {x}"));
    });

    do_something(|| {
        some_vec.iter().for_each(|x| println!("The number is: {x}"));
    });
}

12.1.2 FnOnce、FnMut、Fnの関係

1
2
3

pub trait Fn: FnMut
pub trait FnMut: FnOnce
pub trait FnOnce

12.1.3 クロージャはすべて一意である

12.1.4 クロージャの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#[derive(Debug)]
struct City {
    name: String,
    years: Vec<u32>,
    populations: Vec<u32>,
}

impl City {
    fn change_city_data<F>(&mut self, mut f: F)

    where
        F: FnMut(&mut Vec<u32>, &mut Vec<u32>),
    {
        f(&mut self.years, &mut self.populations)
    }
}

fn main() {
    let mut tallinn = City {
        name: "Tallinn".to_string(),
        years: vec![1372, 1834, 1897, 1925, 1959, 1989, 2000, 2010, 2020],
        populations: vec![3_250, 15_300, 58_800,
            119_800, 283_071, 478_974,
            400_378, 406_703, 437_619,
],
        ],
    };

    tallinn.change_city_data(|x, y| {
        x.push(2030);
        y.push(500_000);
    });

    tallinn.change_city_data(|years, populations| {
        let new_vec = years
            .iter_mut()
            .zip(populations.iter_mut())
            .take(3)
            .collect::<Vec<(_, _)>>();
        println!("{new_vec:?}");
    });

    tallinn.change_city_data(|x, y| {
        let position_option = x.iter().position(|x| *x == 1834);
        if let Some(position) = position_option {
            println!(
                "Going to delete {} at position {:?} now.",
                x[position], position
            );
            x.remove(position);
            y.remove(position);
        }
    });

    println!(
        "Years left are {:?}\nPopulations left are {:?}",
        tallinn.years, tallinn.populations
    );
}

12.2.2 implトレイトでクロージャを返す

12.3 Arc

Arc: アトミック参照カウンター.

12.4 スコープ付きスレッド

12.5 チャンネル

12.5.1チャンネルの基本

12.5.2 チャネルの実装

まとめ

• クロージャーは他のクロージャーとは異なる型を持つ. これらに共通するのはどのトレイト(Fn, FnMut, FnOnce)を実装しているか, そのシグネチャである.
• クロージャーを入力として使用するとき, 最初にそれを関数として想定してどの引数を取って何を返すかを考えればよい. その後fnを必要なクロージャートレイトに変える. Fnは参照で受け取り, FnMutは可変参照で受け取り, FnOnceは値で受け取る.
• impl Traitは通常のジェネリクスよりも柔軟な部分とそうでない部分がある. 違いを実感する最良の方法は練習. 通常のジェネリクスを使用している部分でimpl Traitが使えるか試すと良い. コンパイラが教えてくれる.
• 通常のスレッドがアイテムをキャプチャすると, それらは'staticライフタイムを持つ必要がある. これによってスレッドを生成して忘れることができるか, .join()を使用してスレッドの終了を待てる.
• 標準ライブラリのchannelでは好きなだけ送信者を作れる. これに慣れるためにチャンネルを作り, 構造体のパラメータとして, 関数の入力として, 独自のスレッド内など考えられるすべての場所に送信者を置くとよい.
• スコープ付きスレッドを使用すると'staticライフタイムについて考えなくてもスレッドが使える. ただしスレッドが最終的に終了することを確認しなければならない. 終了しない場合, そのスコープも終了せず, プログラムが永遠に終了しなくなる可能性がある.

Chapter13 BoxとRustのドキュメント¶

• Rustドキュメントを読む
• 属性(Attribute)は小さな追加情報である
• Boxは多くの柔軟性を提供するスマートポインターである

13.1 Rustドキュメントを読む

13.1.2 検索

13.1.4 トレイトに関する情報

ファイルとモジュールは第15章で学習するもう一つの主題.

13.2 ボックス

ボックスは「スマート ポインター」と呼ばれる. &参照(一種のポインタ)で, それ以外にもできることがある.

再帰的な構造体を作成したいときにBoxが使える. ただしRustではあまり再帰的な構造体を使わない.

13.2.2 トレイトの周囲にボックスを配置する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

trait JustATrait {}

enum EnumOfNumbers {
    I8(i8),
    AnotherI8(i8),
    OneMoreI8(i8),
}
impl JustATrait for EnumOfNumbers {}


fn returns_just_a_trait() -> Box<dyn JustATrait> {
    let some_enum = EnumOfNumbers::I8(8);
    Box::new(some_enum)
}

13.2.3 ボックスを使用して複数のエラータイプを処理する

13.2.4 具体的なタイプへのダウンキャスト

Chapter14 テストとテストからのコードの構築¶

• クレートとモジュールを使用してコードを構造化して, 他の人がコードを使用する方法を制限する.
• テストを使用してコードが正しく実行されることを証明する
• 最初にテストを記述してからコードを記述するテスト駆動開発の使用

14.1.1 モジュールの基本

privateでコンパイルエラー.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

mod print_things {
    use std::fmt::Display;

    fn prints_one_thing<T: Display>(input: T) {
        println!("{}", input)
    }
}

fn main() {
    use print_things::prints_one_thing;

    prints_one_thing(6);
    prints_one_thing("Trying to print a string...".to_string());
}

次のコードはビルドが通る.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

mod print_things {
    use std::fmt::Display;

    pub fn prints_one_thing<T: Display>(input: T) {
        println!("{}", input)
    }
}

fn main() {
    use print_things::prints_one_thing;

    prints_one_thing(6);
    prints_one_thing("Trying to print a string...".to_string());
}

14.1.2 pubキーワードの仕組みの詳細

14.1.3 モジュール内のモジュール

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

mod country {
    fn print_country(country: &str) {
        println!("We are in the country of {country}");
    }
    pub mod province {
        fn print_province(province: &str) {
            println!("in the province of {province}");
        }
        pub mod city {
            pub fn print_city(country: &str, province: &str, city: &str) {

                crate::country::print_country(country);
                super::super::print_country(country);

                crate::country::province::print_province(province);
                super::print_province(province);
                println!("in the city of {city}");
            }
        }
    }
}

fn main() {
    country::province::city::print_city("Canada", "New Brunswick", "Moncton");
}

14.2 テスト

14.2.1 #[test]を追加するだけでテストになります

1
2
3
4

#[test]
fn two_is_two() {
    assert_eq!(2, 2);
}

14.2.2 テストが失敗した場合に何が起こるか

14.2.3 複数のテストの作成

14.3.1 計算機の構築: テストから始める

まとめ

• コードのモジュールへの配置は型のどの部分を公開する必要があるかを考え始める良い方法.
• Rustはデフォルトですべてをプライベートにする. 単純にpubコードをコンパイルするために必要なときにいつでもキーワードを使える.
• または型のパラメーターへのアクセスを許可したくない場合はコードを書き直せる.
• テスト関数はmain()のようなものです. 引数を取らないからです.
• #[cfg(test)] テストコードをオーバーテストして, テストを実行しない限りコードをコンパイルする必要がないかコンパイラーに知らせます. テストコードを他のコードの近くに置いておくこともできますが, 注釈を忘れないようにしてください。
• 最終製品がどのようなものにしたいのかがすでにわかっている場合, テスト駆動開発は最適です。また、最終製品がどのようなものにしたいかをある程度知っている場合にも役立ちます。テストを書いていくと、何を作ろうとしているのかがより明確に理解できるようになります。
• TDDでは最初はすべてのテストが失敗します. 思いつくだけ多く書いてから それらを合格させるコードを書き始めてください。

Chapter15 デフォルト、ビルダーパターン、およびDeref¶

• Defaultトレイトの利用
• ビルダーパターンで型の生成方法を制御する
• DerefとDerefMutの利用, 他のタイプのメソッドを盗んで自分のメソッドで使用する.

構造体のすべてのパラメーターを記述する代わりに, メソッドを連鎖させて変数を宣言できるビルダーパターンを学習する. Derefを使うと他の人の型を内部に保持する型を簡単に作れ, その上に独自のメソッドを追加できる.

15.1 デフォルトの実装

• Defaultトレイトのドキュメント

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#[derive(Debug)]
struct Character {
    name: String,
    age: u8,
    height: u32,
    weight: u32,
    lifestate: LifeState,
}

#[derive(Debug)]
enum LifeState {
    Alive,
    Dead,
    NeverAlive,
    Uncertain,
}

impl Default for Character {
    fn default() -> Self {
        Self {
            name: "Billy".to_string(),
            age: 15,
            height: 170,
            weight: 70,
            lifestate: LifeState::Alive,
        }
    }
}

fn main() {
    let character_1 = Character::default();

    println!(
        "The character {:?} is {:?} years old.",
        character_1.name, character_1.age
    );
}

• Defaultはトレイトであるため, 実装するとDefault型を必要とするあらゆるものに型を渡せる. 場合によっては必要な関数やトレイトに出会う. .unwrap_or_default().
• 型は実装する別の構造体または列挙型のパラメーターである必要がある場合がある. 実装するにはDefaultを使用して#[derive(Default)], 型のすべてのパラメータもそれを実装する必要がある.
• Defaultを持つ型のユーザーにその使用方法の一般的なアイデアを提供する. たとえば一般的にはnew()やcreate()のようなメソッドを用意するとよが, 全ての設定をいちいち気にしなくてもよいDefaultがあると便利.
• Defaultは構造体のパラメータを操作するときに非常に便利.

15.2 ビルダーパターン

15.2.1 ビルダーメソッドの記述

ビルダーメソッドの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

fn height(mut self, height: u32) -> Self {
    self.height = height;
    self
}

fn weight(mut self, weight: u32) -> Self {
    self.weight = weight;
    self
}

fn name(mut self, name: &str) -> Self {
    self.name = name.to_string();
    self
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#[derive(Debug)]
struct Character {
    name: String,
    age: u8,
    height: u32,
    weight: u32,
    lifestate: LifeState,
}

#[derive(Debug)]
enum LifeState {
    Alive,
    Dead,
    NeverAlive,
    Uncertain,
}

impl Character {
    fn height(mut self, height: u32) -> Self {
        self.height = height;
        self
    }

    fn weight(mut self, weight: u32) -> Self {
        self.weight = weight;
        self
    }

    fn name(mut self, name: &str) -> Self {
        self.name = name.to_string();
        self
    }
}

impl Default for Character {
    fn default() -> Self {
        Self {
            name: "Billy".to_string(),
            age: 15,
            height: 170,
            weight: 70,
            lifestate: LifeState::Alive,
        }
    }
}

fn main() {
    let character_1 = Character::default().height(180).weight(60).name("Bobby");
    println!("{character_1:?}");
}

15.2.2 ビルダーパターンへの最終チェックの追加

ビルダーパターンに追加する最後のメソッドはふつう{.build()}で, このメソッドは一種の最終確認.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

fn build(mut self) -> Result<Character, String> {
    if self.height < 200
        && self.weight < 300
        && !self.name.to_lowercase().contains("smurf")
    {
        self.can_use = true;
        Ok(self)
    } else {
        Err("Could not create character. Characters must have:
1) Height below 200
2) Weight below 300
3) A name that is not Smurf (that is a bad word)"
            .to_string())
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

#[derive(Debug)]
struct Character {
    name: String,
    age: u8,
    height: u32,
    weight: u32,
    lifestate: LifeState,
    can_use: bool,
}

#[derive(Debug)]
enum LifeState {
    Alive,
    Dead,
    NeverAlive,
    Uncertain,
}

impl Default for Character {
    fn default() -> Self {
        Self {
            name: "Billy".to_string(),
            age: 15,
            height: 170,
            weight: 70,
            lifestate: LifeState::Alive,
            can_use: true,
        }
    }
}

impl Character {

    fn height(mut self, height: u32) -> Self {
        self.height = height;
        self.can_use = false;
        self
    }

    fn weight(mut self, weight: u32) -> Self {
        self.weight = weight;
        self.can_use = false;
        self
    }

    fn name(mut self, name: &str) -> Self {
        self.name = name.to_string();
        self.can_use = false;
        self
    }

    fn build(mut self) -> Result<Character, String> {
  if self.height < 200
        && self.weight < 300
        && !self.name.to_lowercase().contains("smurf")
            self.can_use = true;
            Ok(self)
        } else {
            Err("Could not create character. Characters must have:
1) Height below 200
2) Weight below 300
3) A name that is not Smurf (that is a bad word)"
                .to_string())
        }
    }
}

    let character_with_smurf = Character::default()
        .name("Lol I am Smurf!!").build();
    let character_too_tall = Character::default()
        .height(400)
        .build();
    let character_too_heavy = Character::default()
        .weight(500)
        .build();
    let okay_character = Character::default()
        .name("Billybrobby")
        .height(180)
        .weight(100)
        .build();

    let character_vec = vec![
        character_with_smurf,
        character_too_tall,
        character_too_heavy,
        okay_character,
    ];

    for character in character_vec {
        match character {
            Ok(character) => println!("{character:?}\n"),
            Err(err_info) => println!("{err_info}\n"),
        }
    }
}