tailwind 中央寄せマニュアル 16
cssの中央寄せ種類ありすぎ問題。
何度も見返すのが面倒などのまとめる。 後から追記もするかも。
前提
基本的に、中央寄せは一つのプロパティに一つの軸だけしか対応していない。縦横中心に寄せたいなら2つのプロパティを指定する必要がある。
要点3つ
中央寄せといってもx軸とy軸でちがいあり、何を対象にして中央寄せるするのかによっても変わってくる。そして、交差軸も考慮しないといけない。 交差軸はいかに書いてある。今回は交差軸がrowの場合を想定する。
そしてぱっと見で分かるように以下の3点にまとめる。
- 何軸に中央寄せするか
- どの要素が中央寄せされるか
- どの要素に記載するか
想定する要素
要素は2種類。すべてを囲む親要素と、それに含まれる子要素。
<div> <!-- 親要素 --> <div>01</div> <!-- 子要素 --> <div>02</div> <div>03</div> </div>
中央寄せ一覧
１. justify-center
※flexが必要 1. y軸に寄せる 2. コンテナ（親要素）に囲まれた子要素を中央寄せ 3. コンテナ（親要素）に記載する
2. items-center
- x軸に寄せる
- コンテナ（親要素）に囲まれた子要素を中央寄せ
- コンテナ（親要素）に記載する
3. text-center
- y軸に寄せる
- 自要素の文字を中央寄せ
- 自要素に記載
4. mx-auto
- x軸に寄せる
- 自要素を中央寄せ
- 自要素に記載
5. place-content-center
※flexが必要 1. x軸、y軸に寄せる 2. コンテナに入っている子要素を上下左右中央寄せ 3. 親要素に記載
6. content-center
f※flexが必要 1. x軸に寄せる 2. コンテナに入っている子要素を央寄せ 3. 親要素に記載
6. content-center
f※flexが必要 1. x軸に寄せる 2. コンテナに入っている子要素を央寄せ 3. 親要素に記載
tailwind color カスタム15
tailwindを使いっているとき、登録されている色以外を使いたいときがある。
そのためには、Railsの場合config/tailwind.config.jsに記載しなければいけない
実例
config/tailwind.config.js
module.exports = { theme: { extend: { colors: { purple: '#3F3D56', 呼び出すときの名前: '登録したい色' }, }, }, } ```` すごく簡単でした。
cssのposition relativeとabosolute 14
今、自作アプリをcssでコーディングしている。
その中で、positionの「relative」と「absolute」が他のコードを読むにしても、書くにしてもあいまいだと思ったのでまとめる。
positionについて
要素の配置を適用範囲内で指定の場所に動かせる。
top、left、right、bottomを使い、場所を指定する。
positionを指定しない状態だと、基本的にpaddingやmargin、その他にも何かしらの要素
を挟み地続きで配置を決めていくが、positionの場合それらを度外視して指定できる。
自分の理解ですごく簡単に言うと、デフォルトは詰め詰め状態。
positionは好きな所におけるので、スカスカ状態。
もう一つ特徴は、他要素のレイヤーから独立した階層を持つ。気がする。
relativeとabsoluteの違い
結局、relativeとabsoluteの何が違うか。それは適用範囲だ。
relativeは親要素があるとその範囲内で独立し、自由に指定できる。
一方、absoluteは親要素がrelative意外だと、親要素関係なくページ内を指定しないといけない。
うまく説明できていない。
もう少し理解が必要かも。
zipメソッド 13
zipメソッドについて
AtCoderの「B - Trick Taking 」の問題でもっとスリムにできないか他のコードを見てた時に見つけた。
概要
このメソッドは自身の配列と渡される引数の配列から、それぞれのインデックス番号が同じものを一つの配列にまとめるメソッド。
注意点
実例
p [1,2,3].zip([4,5,6], [7,8,9]) # => [[1, 4, 7], [2, 5, 8], [3, 6, 9]] p [1,2].zip([:a,:b,:c], [:A,:B,:C,:D]) # => [[1, :a, :A], [2, :b, :B]] p [1,2,3,4,5].zip([:a,:b,:c], [:A,:B,:C,:D]) # => [[1, :a, :A], [2, :b, :B], # [3, :c, :C], [4, nil, :D], [5, nil, nil]] p [1,2,3].zip([4,5,6], [7,8,9]) { |ary| p ary } # => [1, 4, 7] # [2, 5, 8] # [3, 6, 9] # nil
使用される場面予想
複数の配列を扱う場合かつ、それらの要素を関連付ける必要があるとき。
他サイトのイメージでわかりやすかったのは、Excelで縦に一次元での配列を2つ作る。それらは関連性があり一つにまとめたい。 それにzipメソッドを使う。
その図がまさにジッパーのように見える。
httpについて 12
だいぶ前に読んだ『webを支える技術』を読み直してる。
その中で昨日読んだhttpについてまとめる。
HTTPとは
すごく簡単に言うとHTTPはクライアント（webサイトを見てるあなた）の、このサイトを見たいという希望をかなえるため、そのwebサイトの情報を持っているいるサーバーに向けてこの情報をくださいとリクエストを送り、それの情報が送られてきたら受けとって、解析。必要があれば追加のリクエストを送るプロトコル。
※難しい言葉のプロトコルについて
通信を必要とするものはたくさんあり、それらに使われているOSや端末もいっぱいある。それらは独自開発などにより、普通通信するのが難しい。（日本人と外国人みたいなもの）
その通信を可能にするのが通信プロトコル。これらのプロトコルはオープンになっている約束事みたいなもので、これに対応させとけば他の端末とも通信が可能になる。
（世界の公用語みたいなもの。これさえ覚えておけば大体との人と意思疎通できるみたいな）
やり取りする情報
HTTPの送るリクエストの形式はリクエストライン、ヘッダ、ボディに分けられる。
リクエストライン
ここではメソッド（getなど）、リクエストURI（情報を持っているサーバーの住所）、
プロトコルバージョン（HTTPのバージョン）が送られる。
ヘッダ
ボディに記載されるメッセージのメタデータが記載される。メタデータはボディのメッセージはこんなデータだよ。って識別できるようにしたもの。
データのデータだからメタデータ。
ボディ
リクエスト先に送る本質的な情報。手紙の本文みたいなもの。
逆に、これらの情報を受けとった側のサーバーから送られてくる情報はステータスライン、ヘッダ、ボディに分けられる。
後、特徴はステートレス性などがあげらる。
ここまで書いたけど、あまりに内容が長すぎる。
これ以上は書かん。
テーマの切り分けをミスった。
今度からきをつけよ。
S3 について 11
今日はS3について
概要
S3はawsが提供するクラウドストレージサービス。要は外付けストレージ。 今回の演習は画像の保存に使った。
ではなぜ、webサーバーに保存しないのか。 1. webサーバーへのリクエストを減らし、負荷を分散。 2. webサーバーのストレージが画像でいっぱいになるのを防ぐ 3. サーバー台数を増やしやすくする 4. コンテンツ配信サービスから配信することで、画像を高速化できる
重要概念
重要な概念。用語は3つ。
- バケット：データの保存場所
- オブジェクト：でーた本体。ファイル
- キー：オブジェクトの格納URLpath
今回、保存した画像で考えると バケット＝s3で作成した場所。 オブジェクト＝画像ファイル キー= 画像の保存先を示すURL
よくある利用シーン
- 静的コンテンツの配信（多分画像とか）
- バッチ連携用のファイル置き場（s3にファイルを置いて、バッチでそのファイルを参照して処理）
- ログなどの出力先（定期的にログを送る）
- 静的ウェブホスティング(静的なウェブサイト（ランニングページなど）をS3から公開する)
モジュールバンドラとは？10
本当は「jsbundling-rails」や「cssbundling-rails」について
まとめようと思ったけれど、それ以外の知識が曖昧だったので
何回かにわけてやっていこうと考え中。
それで今回のテーマは「モジュールバンドラってなーに？」
ということ。
少し調べたら以下の記事がわかりやすかった。
モジュールバンドラとは
まずモジュールは上記の記事で以下のようにまとめられていた。
モジュールというのはフロントエンドの開発においては「関数」や「コンポーネント」といった機能ごとに分けたファイルになります。
そして「バンドラ」とは「bundle」の事で、意味は「束、包み、一つにまとめた物」などだ。つまりモジュールバンドラは関数やコンポーネントをまとめた物のこと。
まあ、直訳すればその通りなのだがそんなのは誰だってわかる。ようはイメージが曖昧なわけで...
ということで、具体的な開発過程で例えると
cssやjsのプログラムを書くときすべてを一つのファイルにまとめて書かない。
なぜなら、長々としたコードは後々見ずらいし開発途中でもよくわからなくなるし、
共同開発もできない。
そんな時、それぞれの機能や、ブラウザのページにファイルを分けて開発する。
それらのファイルをありえず、モジュールだと思っておけばいいと思う。
そしてそれらはブラウザにファイルを取り込むときに一つにまとめる必要がある。
それはなぜか、それは次に簡単に書くつもり。
とりあえず、まとめる必要がある。それをに担うのが「バンドラ」。
まとめると、
開発で、メンテナンス、開発のしやすさなどの理由でモジュールに分けて開発する。
一方、ブラウザに取り込むときにはそれらのファイルを一つにまとめないといけない。
また、ファイルをまとめるということは依存関係などもあり。超面倒。
そんな時、難しい事をすべてやってまとめてくれるのがモジュールバンドラです！
なぜモジュールをまとめる必要がある？
どうやら、理由は「HTTP」の仕組みにあるよう。
HTTPは一度にできるリクエスト数に限りがある。そして、その回数は表示速度に影響あり。だから、HTTPはできるだけリクエスト数を減らしたい。
そして、scriptファイル（<script src="./sample.js">見たいなやつ）が多いとその分だけリクエストの数が増える。だけど、エンジニアは開発しやすいようscriptファイルをモジュールごとにいっぱい作る。
だから、モジュールバンドラが必要。
エンジニアが量産したファイルがそのままだと、HTTPがリクエスト回数が多くなる。
それをHPPTに渡す前にモジュールバンドラが一つにまとめて渡してくれる。
結果、モジュールが多くなっても通信速度などを考えず開発しやすい環境を維持できる。モジュールバンドラに感謝！
