<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#unicode%E3%81%AE%E6%AD%A3%E8%A6%8F%E5%8C%96">unicodeの正規化</a></li>
<li><a href="#solr%E3%82%92%E4%BD%BF%E3%81%86">Solrを使う</a>
<ul>
<li><a href="#%E3%83%80%E3%82%A4%E3%83%8A%E3%83%9F%E3%83%83%E3%82%AF%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89">ダイナミックフィールド</a></li>
<li><a href="#%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9">クエリの書き方</a></li>
<li><a href="#%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%AE%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90">日本語の構文解析</a></li>
<li><a href="#cabocha%E3%81%A7%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90">cabochaで構文解析</a></li>
<li><a href="#%E7%B2%BE%E5%BA%A6%E6%8C%87%E6%A8%99">精度指標</a></li>
</ul>
</li>
<li><a href="#%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%83%9E%E3%82%A4%E3%83%8B%E3%83%B3%E3%82%B0">テキストマイニング</a>
<ul>
<li><a href="#tf-idf">tf-idf</a></li>
<li><a href="#n-gram">n-gram</a></li>
<li><a href="#mb25">MB25</a></li>
<li><a href="#ldalatent-dirichlet-allocation">LDA(Latent Dirichlet Allocation)</a></li>
<li><a href="#%E7%9F%A5%E8%AD%98%E6%83%85%E5%A0%B1">知識情報</a></li>
</ul>
</li>
<li><a href="#%E9%9B%91%E5%A4%9A%E3%82%81%E3%82%82">雑多めも</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>機械学習その他もろもろで文章をこねくり回す機会が増えたが、<br>
前に買ったまま放置していた「Pythonで動かして学ぶ 自然言語処理入門」があったので引っ張り出して学習することにした<br>
自然言語処理の基礎力がないので、機械学習ばかりを調べるのではなく、自然言語処理の学習に活かせる基礎ついて学べればと思う</p>
<h1 id="unicodeの正規化">unicodeの正規化</h1>
<p>自然言語処理を行う際の前処理の一つに、Unicodeの正規化がある<br>
具体的には半角全角をそろえたり、①と1のように等価な文字をまとめてくれる</p>
<p>正規化の方法は4種類ある</p>
<ul>
<li>NFD
<ul>
<li>Normalization Form Canonical Decomposition</li>
</ul>
</li>
<li>NFC
<ul>
<li>Normalization Form Canonical Composition</li>
</ul>
</li>
<li>NFKD
<ul>
<li>Normalization Form Compatibility Decomposition</li>
</ul>
</li>
<li>NFKC
<ul>
<li>Normalization Form Compatibility Composition</li>
</ul>
</li>
</ul>
<p>Canonicalは正規の、という意味<br>
前者二つが同一としてみなす条件が厳しく(正準等価性)、後者二つが緩い  (互換等価性)
NFDの後に再度合成するのがNFC、NFKDの後再度合成するのがNFKC<br>
NFKCがよくつかわれているみたい。NFだと①と1を区別するが、NFKだと区別しない</p>
<p>正規化がそもそも文字の合成と分解、という概念で行われるらしい<br>
文字の合成は規定文字と結合文字の組み合わせによる結合文字列を単一の合成済み文字にする手続き。か゛をがにするって感じかな</p>
<p>合成と分解は<code>等価性</code>という概念に基づく。この等価性が先述の通り2種類ある<br>
Canonicalは機能的に等しく視覚的にも識別不可能であるべき文字を識別する<br>
Compatibilityは視覚的に異なり、意味的にも異なるかもしれないものを識別する<br>
後者が緩い</p>
<h1 id="solrを使う">Solrを使う</h1>
<p>SQLiteは経験があったが、Solrはなかったのでこの本で触って覚えたことをメモしようと思う<br>
とりあえず本のダウンロード手順が面倒だったのでDockerで構築</p>
<p>検索対象のデータセットのことをコアと呼ぶ。<code>solr create -c doc</code>で作成可能</p>
<h2 id="ダイナミックフィールド">ダイナミックフィールド</h2>
<p>事前にフィールド名と型を定義しなくてもデータを突っ込める仕組み。suffixで型が決まる</p>
<ul>
<li>_iで整数</li>
<li>_txt_jaで日本語</li>
<li>_sで文字列</li>
</ul>
<h2 id="クエリの書き方">クエリの書き方</h2>
<p><code>content_txt_ja:なんとか</code> AND <code>content_txt_ja:かんとか</code> のようにANDかORでつなぐ<br>
*でn個の任意の文字列<br>
単語を石油ガスだと、石油とガスで検索されるが、""で囲むと石油ガスのみが対象になる</p>
<h2 id="日本語の構文解析">日本語の構文解析</h2>
<p>係り受け解析、句構造解析がある<br>
この本ではCaboChaを使って構文を解析する<br>
SudachiやMecabなど自然言語処理ライブラリは食べ物が多い</p>
<p><code>私はトンカツを食べて午後に筋トレをした</code>のような文章があるとき、私は～食べて、のように主語と述語などの句の依存関係を解析するものを係り受け解析と呼ぶそうな</p>
<p>文章の区切りを<code>文節</code>と呼ぶ。<br>
文章を解析して、文節間の修飾関係による文法構造を<code>係り受け構造</code>と呼ぶ<br>
文節じゃなくて単語の修飾関係を表す流派もあるそう。英語は単語が一般的<br>
日本語はてにをはがあるからな～</p>
<h2 id="cabochaで構文解析">cabochaで構文解析</h2>
<p>installめっちゃしんどかった...</p>
<ul>
<li>品詞について学ぼう
<ul>
<li>名詞</li>
<li>動詞</li>
<li>形容詞</li>
<li>連体詞
<ul>
<li>あの、この、その、たいした
<ul>
<li>語尾がの、る、な、た・だ、になるそう</li>
</ul>
</li>
<li>など。名詞を修飾し、活用がない自立語</li>
</ul>
</li>
<li>副詞</li>
<li>接続詞</li>
<li>接頭詞</li>
<li>感動詞</li>
<li>フィラー
<ul>
<li>あ～、えっと～、その～</li>
</ul>
</li>
<li>記号
<ul>
<li>!$。、など</li>
</ul>
</li>
<li>助詞
<ul>
<li>は、が、を</li>
<li>格助詞
<ul>
<li>庭の～、本を～、みたいなね</li>
</ul>
</li>
<li>接続助詞
<ul>
<li>朝起きて～</li>
<li>XXになると～</li>
</ul>
</li>
<li>副助詞
<ul>
<li>この本は、この本だけ、この本まで、この本など</li>
</ul>
</li>
<li>終助詞
<ul>
<li>～ですか？、～ですよ、など話し手から聞き手へ</li>
</ul>
</li>
</ul>
</li>
<li>助動詞
<ul>
<li>た、ます、れる、られる</li>
<li>用言(動詞、形容詞、形容動詞)や体言(モノことを表す活用のない言葉、名詞)に意味を添える語</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Parseするとtreeができて、その中にchunkがあり、chunkが複数tokenを含む</p>
<p>グーグル、みたいな辞書になさそうな単語を入れるとlemmaが*になる</p>
<h2 id="精度指標">精度指標</h2>
<p>文章を分割し、アノテーションを付与する場合、その精度を確認したいことがある。<br>
自然言語処理は人間がやったとしても結果が100%にならないものが多い。「赤いボールの下にあるテーブル」という文章では、ボールとテーブルどちらが赤いかわからない</p>
<ul>
<li>Recall(再現率)
<ul>
<li>抽出すべきもののうち、正しい対象を抽出した割合
<ul>
<li>こっちは全体で10あるけど3だったら3/10</li>
</ul>
</li>
<li>100% - 抽出漏れの割合</li>
</ul>
</li>
<li>Precision(適合率)
<ul>
<li>抽出されたもののうち正しい対象を抽出した割合
<ul>
<li>5つ抽出して、あたりが3だったら3/5</li>
</ul>
</li>
<li>100% - 誤抽出の割合</li>
</ul>
</li>
</ul>
<p>この両方の指針でもって、対象のみをもれなく取得できると精度が高い</p>
<h1 id="テキストマイニング">テキストマイニング</h1>
<p>テキストデータの集合を分析して、何かしらの知見を見出すことを指す<br>
ここでは統計的な手法を覚える</p>
<p>トレンドとか、類似文章の検索とか、カテゴライズとか</p>
<h2 id="tf-idf">tf-idf</h2>
<p>term frequencyとinverse document frequency。前者がある文書の単語の出現具合。後者がその単語が出てくる文書の割合の逆数(全文書数をその単語が出てくる文書で割った値)。他であまり使われず、少ない文書で多く登場する単語は重要だよね～と判断する指標<br>
ある単語の重要度的なもの</p>
<p>sklearnのTfidfVectorizerを使うと、文書*単語のtf-idf行列を作れる。<br>
この行列でコサイン類似度を取ると、単語の出現頻度で似ている文書を探すことができる</p>
<h2 id="n-gram">n-gram</h2>
<p>言語モデルの一つ。単語の出現確率が、その前のn-1個の単語にのみ依存すると仮定したモデル<br>
テキストをn文字ずつseekして抜き出したものも同じ名前だった気がする。文脈によって違うのか？<br>
言語モデルとしてのものと、転置インデックスの文脈とかがあるっぽ</p>
<h2 id="mb25">MB25</h2>
<p>tf-idfを発展させたもの<br>
文書の長さを考慮するようになり、一致する単語が多くても、文書が長いときはその分スコアが下がるように調整されている。tf-idfは長い文章に対してスコアが大きくなるとかなんとか<br>
文書の集合全体で登場する単語のスコアが低いのはtf-idfと同じ</p>
<h2 id="ldalatent-dirichlet-allocation">LDA(Latent Dirichlet Allocation)</h2>
<p>トピックモデルの一つでテキストをクラスタリングするときに使われる<br>
サンプルだけだとよーわからんかったな...</p>
<p>これもまた文章の中の単語の分布であれこれ判断する系っぽい</p>
<h2 id="知識情報">知識情報</h2>
<p>DBPedia、WordNet、Word2Vecについて説明される<br>
DBPediaは昔触ったことがあった。SPARQLというグラフDBへの問い合わせ言語、で問い合わせるんだったはず</p>
<h1 id="雑多めも">雑多めも</h1>
<ul>
<li>wikiのデータであれこれやっていく感じのようだ。データのparseには<code>beautifulsoup</code>を使っている。だいぶ楽に引っこ抜けるな</li>
<li><code>str.maketrans</code>関数は使ったことなかった。変換表を作って、strのtranslate関数に投げ込める</li>
<li>掛け算の対数値は、対数値の足し算と等しい。なので計算では対数の足し算が使われる。0~1の値を乗算し続けると小さくなっちゃうからそれの回避方法
<ul>
<li>$log_{ab} = log_a + log_b$</li>
</ul>
</li>
</ul>

Pythonで動かして学ぶ 自然言語処理入門を読んだ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#api%E3%81%AE%E3%83%A2%E3%83%BC%E3%83%89">APIのモード</a></li>
<li><a href="#%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AE%E7%A8%AE%E9%A1%9E">モデルの種類</a></li>
<li><a href="#%E3%83%91%E3%83%A9%E3%83%A1%E3%83%BC%E3%82%BF">パラメータ</a></li>
<li><a href="#token%E6%95%B0">token数</a></li>
<li><a href="#llamaindex">LlamaIndex</a>
<ul>
<li><a href="#ragretrieval-augmented-generation">RAG(Retrieval Augmented Generation)</a></li>
</ul>
</li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>ChatGPTのAPIでできることについてまとめる<br>
主に文章の感情分析や分類を手軽にできるんじゃないかというとことに興味がある<br>
使い方を把握していないので、まずはそこから</p>
<h1 id="apiのモード">APIのモード</h1>
<p>APIにはいくつかモードがある</p>
<ul>
<li>Chat</li>
<li>Insert</li>
<li>Edit</li>
<li>Complete</li>
</ul>
<p>Chat以外は7/6時点だとlegacyなようだ</p>
<p>全部統一なのかと思いきや、Chatの応答だったりEmbeddingの出力だったり思ってたより色々ある</p>
<h1 id="モデルの種類">モデルの種類</h1>
<p>chatならgpt-3.5-turbo、のようにモデルがちょいちょい違う</p>
<p>gpt3.5と4.0は5月時点でファインチューニングができない。やるにしても結構なサイズのRAMがあるGPUが必要なはず</p>
<p>embeddingで使うモデルは<code>text-embedding-ada-002</code>が安くて精度が良い</p>
<h1 id="パラメータ">パラメータ</h1>
<ul>
<li>Temperature
<ul>
<li>生成する内容のランダムさ。0.9とかにすると創造的になる</li>
</ul>
</li>
<li>Maximum length
<ul>
<li>出力する最大トークン数。節約にも使えそう</li>
</ul>
</li>
<li>stop sequence
<ul>
<li>この文字が出たら生成を停止する</li>
</ul>
</li>
</ul>
<h1 id="token数">token数</h1>
<p>gptが扱う文章の単位。あ、で1tokenというような単純な感じではなく、日本語はtoken数が多い(ざっくり英語の2倍)<br>
tokenの数は、tiktokenというライブラリを使うと算出できる<br>
日本語のほうがコストが高いが、英語よりも文章が短くても良かったりするので実際はトントンらしい</p>
<h1 id="llamaindex">LlamaIndex</h1>
<p>基本的な使い方</p>
<ul>
<li>loggingのlevelをDEBUGにしておくと捗る</li>
<li>SimpleDirectoryReaderでlocalのファイルをDocumentクラスに変換できる
<ul>
<li>複数のtxtファイルがあっても読み込んでくれる。楽</li>
<li>ChatGPTのtoken上限があるので、それを超えそうな場合はチャンクに分割される</li>
</ul>
</li>
<li>GPTVectorStoreIndexでindexをDocument[]から作れる
<ul>
<li>この際にもトークンを消費する。embeddingのtokenが使われているのが確認できた</li>
</ul>
</li>
<li>indexからas_query_engineでqueryエンジンを生成し、これに対して質問ができる
<ul>
<li>logの出力から見た感じ、indexから参考のdocumentを索引、その内容をcontextとして埋め込んで、GPTに問い合わせ、という感じのようだ</li>
<li>簡単な質問でもcontextが大きいので543トークン使ってた。一旦token数は考えないようにしよう</li>
<li>標準のpromptはLlamaIndexの<code>default_prompts.py</code>で定義されている</li>
<li>queryの結果の.response、.source_nodesで結果と、参考にしたデータが取得できる</li>
</ul>
</li>
<li>作ったstorageはlocalに保存できる
<ul>
<li>置き場はs3も選べるみたい</li>
</ul>
</li>
<li>Document型って？
<ul>
<li>text以外にembeddingやextra_infoといった情報を持っている</li>
</ul>
</li>
</ul>
<p>あくまで応答なので、queryに固有名詞がないとキツイかも？  一応物語の概要とかは出してくれるけど</p>
<p>LLMPredictorを作るときにChatOpenAIクラスを投げ込めるので、独自のエンドポイント呼び出すときはこいつを使うと良さそう<br>
embeddingにはHuggingFaceのものも使える。精度は知らんが無料である</p>
<h2 id="ragretrieval-augmented-generation">RAG(Retrieval Augmented Generation)</h2>
<p>knowledgeベースからRelevantContextを通ってLLMに情報を渡す仕組みのイメージ<br>
Llamaはここをつなぐ仕組みを用意してくれている</p>
<p>IndexingStageでは<br>
DataSource -> DataLoader -> Documents -> Indexing -> KnowledgeBase</p>
<p>という流れのイメージらしい<br>
特にDocumentがデータを抽象化するレイヤーみたいで、PDFとかAPIのresponseとかを表現する</p>
<p>逆のQueryingStageでは、<br>
KnowledgeBase -> Retriever -> Node Postprocessor->ResponseSynthesizer->QueryEngine|ChatEngine<br>
という流れの模様。Node Postprocessorが取得した文字列をfilterしたりrerankしたりできるそうだ<br>
ResponseSynthesizerはLLMの予備ダサいれいやっぽい</p>
<p>Nodeはtextの文字列とmetadataとrelationshipsを抽象化する軽量な仕組みだそう</p>
<p>今までの検索エンジンの仕組みで、queryがpromptになって、実行がLLMに任されたイメージだなぁ</p>

ChatGPT雰囲気で触る

機械学習及び自然言語処理に入門する

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82%E8%8B%A6%E6%89%8B%E6%84%8F%E8%AD%98%E3%81%8C%E3%81%82%E3%82%8B%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AF">そもそも苦手意識があるところは?</a></li>
<li><a href="#%E9%80%86%E3%81%AB%E9%9B%B0%E5%9B%B2%E6%B0%97%E3%82%8F%E3%81%8B%E3%81%A3%E3%81%A6%E3%81%9D%E3%81%86%E3%81%AA%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AF">逆に雰囲気わかってそうなところは?</a></li>
<li><a href="#%E3%83%AC%E3%82%A4%E3%82%A2%E3%82%A6%E3%83%88">レイアウト</a>
<ul>
<li><a href="#%E5%A4%96%E5%9C%A8%E3%82%B5%E3%82%A4%E3%82%BA%E8%A8%AD%E5%AE%9A%E3%81%A8%E5%86%85%E5%9C%A8%E3%82%B5%E3%82%A4%E3%82%BA%E8%A8%AD%E5%AE%9A">外在サイズ設定と内在サイズ設定</a></li>
<li><a href="#box%E3%81%AE%E6%A7%8B%E9%80%A0">boxの構造</a></li>
</ul>
</li>
<li><a href="#%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BF">セレクタ</a></li>
<li><a href="#%E5%84%AA%E5%85%88%E9%A0%86%E4%BD%8D">優先順位</a></li>
<li><a href="#%E8%A9%B3%E7%B4%B0%E5%BA%A6specificity">詳細度(Specificity)</a></li>
<li><a href="#layout">layout</a>
<ul>
<li><a href="#flexbox">flexbox</a></li>
<li><a href="#grid">grid</a></li>
</ul>
</li>
</ul>
<h1 id="そもそも苦手意識があるところは">そもそも苦手意識があるところは?</h1>
<ul>
<li>flex、grid、floatとかその辺がどういう理屈でレイアウトしているのか</li>
<li>marginの相殺の挙動</li>
<li>width,heightの指定がなんかうまくいかない時があるな〜</li>
</ul>
<h1 id="逆に雰囲気わかってそうなところは">逆に雰囲気わかってそうなところは?</h1>
<ul>
<li>block要素とinline要素があって、それぞれどっちにデフォルトで</li>
<li>詳細度はそんなに混乱せず把握できてると思う
<ul>
<li>けどそらで使うのはまだ無理</li>
</ul>
</li>
</ul>
<h1 id="レイアウト">レイアウト</h1>
<h2 id="外在サイズ設定と内在サイズ設定">外在サイズ設定と内在サイズ設定</h2>
<ul>
<li>widthに100pxとか指定するのは外在サイズ設定で、内部のコンテンツがあふれるとoverflowする</li>
<li>一方で<code>min-content</code>をwidthに指定すると、内在サイズ設定になって中のコンテンツの内容に応じてサイズが変わる</li>
</ul>
<h2 id="boxの構造">boxの構造</h2>
<ul>
<li>すべての要素はBoxである</li>
<li>Boxは外から<code>margin</code> > <code>border</code> > <code>padding</code> > <code>content</code> の順に囲まれてる
<ul>
<li>paddingの領域はscrollバーを含む</li>
<li>逆にoutlineやbox-shadowはmarginの領域に出ていく</li>
</ul>
</li>
<li>box-sizingという設定
<ul>
<li>要素全体の幅と高さをどのように計算するかを設定する</li>
<li>content-boxとborder-boxを覚えておくと良さそう
<ul>
<li>前者の場合、widthが200でborderやpaddingの設定があるとwidthは200+それらの設定の値になる</li>
<li>後者はborder領域込みでサイズが決まる</li>
<li>すべてのbefore/after疑似要素にborder-boxをつけるresetCSSなんかは一般的みたい？</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="セレクタ">セレクタ</h1>
<ul>
<li>[hoge='aaa' s] で大文字小文字を区別する。逆にiで無視する。書き方がいっぱいあるな
<ul>
<li>*=で部分一致、^=で先頭$=で末尾の一致を取る</li>
<li>見通し悪くなりそうだからあまり使いたい気持ちにはならないな...(ライブラリとか作るときは便利かもしれんが)
<ul>
<li>hrefの末尾に一致させてファイルの拡張子に合わせてstyle変えるのは面白そうだった</li>
</ul>
</li>
</ul>
</li>
<li>疑似要素
<ul>
<li>before/after以外にselectionやlistのスタイルを指定する::markerなんてのもある
<ul>
<li>知らないとたどり着けない系</li>
</ul>
</li>
</ul>
</li>
</ul>
<h1 id="優先順位">優先順位</h1>
<ul>
<li>同じ詳細度だとあとに定義されたものが勝つ
<ul>
<li>最近意識してないけど、styleタグやlinkがどこで読み込まれているかは優先順位に影響する</li>
</ul>
</li>
</ul>
<h1 id="詳細度specificity">詳細度(Specificity)</h1>
<ul>
<li>指定の仕方でスコアが違う。例えば*によるユニバーサルな指定は0pointらしい</li>
<li>意外とポイントの桁がでかくて、classは10だけどID指定は100だしinlineは1000
<ul>
<li>importは10000らしい</li>
</ul>
</li>
<li>詳細度の指定で、a.class-a.class-bのようにすると21ポイント。複数クラスの指定があるとその分ポイントがつく</li>
<li>classa.classaのような指定でも詳細度のポイントは稼げる。見たこと無いけどおもろいな</li>
</ul>
<h1 id="layout">layout</h1>
<ul>
<li>column-countを2にした時、liの一覧が親のhightを超えると自動で2列になる、というような表現が可能
<ul>
<li>ニュースの記事とかに使えるとか。パラグラフを並べる</li>
</ul>
</li>
<li>gridは縦横軸ごとにサイズが変わるようなレイアウトに使う
<ul>
<li>2x2のboxの右に、1x1の要素を4つ並べたりとかできる</li>
</ul>
</li>
<li>flexはどっちに寄せるかだったり、要素間のサイズを指定できる
<ul>
<li>gridと違って縦か横かどっちかに向かってのレイアウトになる</li>
</ul>
</li>
</ul>
<h2 id="flexbox">flexbox</h2>
<ul>
<li>rowかcolumnの一方向
<ul>
<li><code>flex-direction</code>で設定。これがmainになる。mainじゃない方をcross-axisと表現する</li>
<li>row-reverseのように逆向きにすることも可能</li>
</ul>
</li>
<li>親のスペースに応じてサイズを可変できる</li>
<li><code>flex-wrap</code> は<code>wrap</code>にするとはみ出した分がcross-axis方向にずれるみたい。二段になる
<ul>
<li><code>nowrap</code>にするとoverflowする</li>
</ul>
</li>
<li><code>flex-flow</code>を使うと、flex-directionとflex-wrapをまとめて指定できる</li>
<li>display:flexを有効にした場合、子componentでflex:1のようにサイズを決めるとそのサイズの割合で描画される。flex:1とflex:2がある時、サイズは1:2になる</li>
</ul>
<h2 id="grid">grid</h2>

CSSを学びたい

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#typescript%E3%81%A8%E3%83%90%E3%83%B3%E3%83%89%E3%83%A9%E3%83%AA%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%82%BF">TypeScriptとバンドラ、リンター、フォーマッタ</a></li>
<li><a href="#nestjsgraphql%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB">nestjs+graphqlのサンプル</a>
<ul>
<li><a href="#%E4%BD%BF%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%83%A1%E3%83%A2">使われているパッケージメモ</a></li>
<li><a href="#model">model</a></li>
</ul>
</li>
<li><a href="#edge-worker%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%98%E3%82%83%E3%82%89%E3%81%BB%E3%81%84">Edge Workerってなんじゃらほい</a>
<ul>
<li><a href="#%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%AE%E6%8B%A1%E5%BC%B5">クライアントの拡張</a></li>
<li><a href="#%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9">ユースケース</a></li>
</ul>
</li>
<li><a href="#tailwindcss%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80">tailwindcss実践入門</a>
<ul>
<li><a href="#%E3%83%A6%E3%83%BC%E3%83%86%E3%82%A3%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AF%E3%83%A9%E3%82%B9%E3%81%AE%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88-">ユーティリティクラスのメリット 　　　　　　　　　　　　　　　　　</a></li>
<li><a href="#%E4%BD%BF%E3%81%84%E6%96%B9">使い方</a></li>
<li><a href="#preflight%E3%81%AE%E6%A6%82%E5%BF%B5">preflightの概念</a></li>
</ul>
</li>
<li><a href="#%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%9Fpackage">出てきたpackage</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>WEB+DB PRESS vol.133がTypeScriptやTailwindcssについて特集していた<br>
サンプルもあったので、勉強になった内容をメモとして残す</p>
<h1 id="typescriptとバンドラリンターフォーマッタ">TypeScriptとバンドラ、リンター、フォーマッタ</h1>
<p>リンターにi11yに関するものがあるのが学びだった<br>
babelや各ツールの立ち位置と、あまり触れていなかったSWCやTurbopackの立ち位置についても学べた<br>
SWCがbabelを置き換えるものだと思ってなかったんだよなぁと(tsのトランスパイラの一つだと思っていた)</p>
<p>ASTを複数のツールが作るので効率が悪いというのはRomeが作られた経緯から認識していたが、SWCとTurbopackの組み合わせが近い感じになることや、esbuildがトランスパイラとバンドラを兼任していて早いことはちゃんと理解できていなかった</p>
<p>全体的にRustが強くて、今後Rustでプラグインを書くことになるかもしれないと思うと、<br>
ちょいちょいRustを勉強しているのも悪いことではないなと思った</p>
<h1 id="nestjsgraphqlのサンプル">nestjs+graphqlのサンプル</h1>
<h2 id="使われているパッケージメモ">使われているパッケージメモ</h2>
<ul>
<li>jsonwebtokenというjwtを扱う名前まんまなpackageがある
<ul>
<li>仕様にしたがってissやaudといったパラメタがpayloadとして指定可能</li>
</ul>
</li>
<li>その他に <code>passport-jwt</code> と <code>@nestjs/passport</code> を使って、tokenのvalidateを実現してるっぽい</li>
</ul>
<h2 id="model">model</h2>
<ul>
<li>DBの文脈のモデルなのでtypeormのEntityデコレータがくっついてる
<ul>
<li>と思いきや@nestjs/graphqlのObjectTypeもくっついてた</li>
<li>両方のmodelが同じ構造体に対応するということなのかな</li>
<li>各attributeにも、typeormとgraphqlのデコレータがそれぞれ付いている
<ul>
<li>動的に計算されるものにはgraphqlのデコレータのみがついてておもろい</li>
</ul>
</li>
</ul>
</li>
<li>ObjectTypeデコレータ
<ul>
<li>これが付与されるとGraphQLのtypeとして解釈される</li>
<li>コードファーストな仕組みなので、modelの定義からschemaが決まるみたい</li>
</ul>
</li>
<li>Fieldデコレータ
<ul>
<li>graphqlで取得するFieldにはFieldデコレータをつける</li>
<li>GraphQLのIDやIntといった型は、明示的にデコレータで指定が必要
<code>@Field(() => GraphQLISODateTime)</code> のようになる</li>
</ul>
</li>
<li>リゾルバの定義
<ul>
<li>*.resolver.tsとして定義されている</li>
<li>これらの定義は*.module.tsにまとめられ、更にmoduleはapp.module.tsにまとめられ、mainでNestFactory.createに渡されていた</li>
</ul>
</li>
<li>リゾルバとrepository
<ul>
<li>DBへのqueryを投げるRepositoryは、*Serviceというクラスにまとめられている</li>
<li>でもってリゾルバがこのサービスを呼び出して結果を受け取るという感じ</li>
<li>serviceとrepositoryがわかれているけど、NestJSの仕組みだからっぽい？</li>
</ul>
</li>
<li>dto
<ul>
<li>*.input.tsという名前になっている。gqlのmutationを投げるときに使われる
<ul>
<li>IsUUIDやIsNotEmptyといった、validation pipeという仕組みが <code>class-validator</code> にある。こいつらもデコレータ</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>覚えるまでにだいぶハードルが高い感触を受けた。DIの仕組みなどは充実しているので、なれるとサクサクいけるのかも</p>
<h1 id="edge-workerってなんじゃらほい">Edge Workerってなんじゃらほい</h1>
<ul>
<li>クラサバの中間にある存在。リバプロのようなイメージだけど、そこにコードでロジックが書ける</li>
<li>エッジで動くのでCDNとリクエストをハンドリングするところは同じ。ロジックを書いてキャッシュ制御の仕組みをより柔軟にできる
<ul>
<li>CDNでもできることはあるが、自前で書けることがポイントのようだ</li>
</ul>
</li>
</ul>
<h2 id="クライアントの拡張">クライアントの拡張</h2>
<ul>
<li>より柔軟なWebWorkerとして、EdgeWorkerを捉えることができるようだ
<ul>
<li>ServiceWorkerは裏でrequest投げてこっそりキャッシュしたり、リクエストをフックしてmockのデータを返したりしてるけど、あれの強い版？</li>
<li>当たり前だけどクライアントに閉じてるかどうかという差がある。キャッシュヒット率はEdgeのほうが高い。色々飛んでくるからね
<ul>
<li>その他ServiceWorkederはcacheの無効化がむずいという側面もあるそう</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="ユースケース">ユースケース</h2>
<ul>
<li>GAのようなトラッキングスクリプトや、タグマネージャのような仕組みをEdge上で動かすユースケースが面白そうだった
<ul>
<li>パフォーマンスも良くなるし、プライバシーも向上するそう</li>
<li>UIスレッドでの同期処理が減れば広告Scriptの鬱陶しさも軽減するとか</li>
</ul>
</li>
</ul>
<h1 id="tailwindcss実践入門">tailwindcss実践入門</h1>
<p>このブログはcss modulesにするかtailwindにするか悩んで、生のcss書く練習要るやろ！ と思って前者にしたのですが、後者に触る機会が減ってしまったので渡りに船</p>
<p>ユーティリティクラスという考え方が面白い。AtomicCSSという近い（というか元祖?）の考え方もあるみたいだけど、クラスに再利用可能な定義だけ持たせて、それを組み合わせて作る<br>
最終的にはただのcssになるし、使わない属性はpargeできるので効率も良い。らしい</p>
<p>本の内容とは別に、そもそも学習コストが高いだのなんだのという批判もあるようだが、その辺の良し悪しに付いては触ってから考えようと思った</p>
<p>tailwindを使う場合コンポーネントは後から見出される。これは実際のデザインを作る過程に近いらしい。答えがない状態でデザインを模索する過程がまずあり、その後コンポーネントとして切り出される、という流れ</p>
<h2 id="ユーティリティクラスのメリット-">ユーティリティクラスのメリット 　　　　　　　　　　　　　　　　　</h2>
<p>本には多くのメリットが記載されていて興味深い<br>
再利用性が高いので結果的にCSSのサイズが小さくなる。同じスタイルを当てたいときに使い回せるから、こういうメリットが出てくる</p>
<p>インラインcssに見えるが、メディアクエリや擬似クラスも使用可能</p>
<h2 id="使い方">使い方</h2>
<p>webpackやviteを使う場合は<code>postcss</code>と<code>autoprefixer</code>を組み合わせるのが一般的らしい</p>
<p><code>Tailwind Play</code> というお試し環境があるらしい。最近はなんでもplaygroundがあっていい時代だ...（逆にもう無いと普及しないのかも）</p>
<h2 id="preflightの概念">preflightの概念</h2>
<p>@tailwind base;で適用されるスタイル<br>
リセットCSS的なものと、ブラウザ間のさいを埋めてくれる(打ち消す?)らしい</p>
<p><a href="https://tailwindcss.com/docs/preflight">ここに書いてある</a></p>
<p>videoやimgがblock要素として扱われるようになっていたり、画像は親の幅に広がるようになっていたりおもろい</p>
<h1 id="出てきたpackage">出てきたpackage</h1>
<ul>
<li>concurrently
<ul>
<li>npmスクリプトを並行して走らせられるパッケージ</li>
</ul>
</li>
<li>jsonwebtoken
<ul>
<li>jsでjwtを扱うためのpackage</li>
</ul>
</li>
<li>passport-jwt
<ul>
<li>jwtによる認可を行うpackage。Auth0のSDKでも使えるとか(依存があるわけではない)</li>
</ul>
</li>
<li>browser-sync
<ul>
<li>ファイルの変更を監視してブラウザのリロードを行ってくれるpackage</li>
<li>複数のブラウザで操作の同期なんてこともできそうそうな
<ul>
<li>複数端末でも可能だそうだから便利だなぁ</li>
<li>普段はchromeでデスクトップ向けにしかアプリ作らないから知らなかった</li>
</ul>
</li>
</ul>
</li>
</ul>

WEB+DB PRESS vol.133 2023覚え書き

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AE%E6%A6%82%E5%BF%B5">サイズの概念</a></li>
<li><a href="#%E9%9A%8E%E5%B1%A4%E6%A7%8B%E9%80%A0">階層構造</a></li>
<li><a href="#%E5%8D%98%E8%AA%9E%E5%B8%B3">単語帳</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>Flutter触るついでにfigmaも勉強するか〜、ということで本を購入したので、<br>
覚えたことや後で見返したい概念をメモっておく</p>
<h1 id="サイズの概念">サイズの概念</h1>
<p>スマホごとにサイズが変わってくるので、pixelはサイズの単位として使えない<br>
pixelが画面にどれだけあるか（サイズと解像度から算出される1インチあたりのピクセル数）を <code>ppi(pixel per inch)</code> や <code>dpi(dots per inch)</code> と呼ぶ。ピクセル密度とも</p>
<p>なので大きさの指定では <code>Point</code> と呼ばれる論理的な単位を使う<br>
このPointに端末ごとの倍率を掛けて実際のサイズを算出する感じらしい</p>
<h1 id="階層構造">階層構造</h1>
<p>Figmaのファイルには、 <code>Page</code> > <code>Frame</code> という階層がある<br>
Frameは入れ子になることができて、アプリの画面になるのは最上位のFrameのみ</p>
<h1 id="単語帳">単語帳</h1>
<ul>
<li><code>ppi</code>, <code>dpi</code> figmaのサイズの単位。論理的な値で、対象の端末のpixel濃度に応じたpixel数の算出に使われる</li>
<li><code>Shape</code> 楕円や多角形のオブジェクト</li>
<li><code>Vector</code> SVGのあれ</li>
<li><code>Text</code> 文字はTextオブジェクトとして扱われる</li>
<li><code>Frame</code> すべてのUI要素はFrameに収まる。画面もボタンの外枠もFrame</li>
<li><code>Group</code> オブジェクトをまとめたもの</li>
<li><code>Component</code> 再利用可能なオブジェクト、らしい</li>
<li><code>Instance</code> Componentのコピー。UnityのPrefabとinstanceみたいな関係っぽい</li>
</ul>

figmaを触る

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#flutter%E3%81%AE%E6%A7%8B%E6%88%90%E8%A6%81%E7%B4%A0">Flutterの構成要素</a></li>
<li><a href="#widget">Widget</a></li>
<li><a href="#%E7%94%BB%E9%9D%A2%E3%81%AE%E9%81%B7%E7%A7%BB">画面の遷移</a></li>
<li><a href="#dart%E3%83%A1%E3%83%A2">Dartメモ</a></li>
<li><a href="#react%E3%81%8B%E3%82%89%E3%81%AE%E5%B7%AE%E5%88%86">Reactからの差分</a></li>
<li><a href="#riverpod%E3%81%AA%E3%81%A9%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E3%83%87%E3%83%BC%E3%82%BF%E7%AE%A1%E7%90%86">Riverpodなどを用いたデータ管理</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>友人がなにか新しい言語やりたいね〜という話をしていて、<br>
どうせならということで複数人巻き込んでFlutterに入門することになったので、メモ置き場とする</p>
<p>作ったアプリは<a href="https://github.com/LTKSK/fodo_app">このリポジトリ</a></p>
<h1 id="flutterの構成要素">Flutterの構成要素</h1>
<ul>
<li>Flutterは3層に別れている。<a href="https://docs.flutter.dev/resources/architectural-overview">公式document</a>
<ul>
<li>Flamework</li>
<li>Engine</li>
<li>Embedder</li>
</ul>
</li>
</ul>
<h1 id="widget">Widget</h1>
<ul>
<li>widgetがUIの設定で、こいつの設定とstateでもってelementが描画されるイメージらしい</li>
<li>padding設定にはPaddingというそのまんまなwidgetがある</li>
<li>Columnでchildrenを縦並べ
<ul>
<li>Spacerで余白を調整する。flexっぽい?</li>
</ul>
</li>
<li>状態を持つStatefullWidgetと状態を持たないStatelessWidgetがある
<ul>
<li>Stateもclassとして定義し、Widget側のcreateState関数で作ったStateクラスのインスタンスを返す</li>
<li>State自体もbuild関数を定義することができる</li>
</ul>
</li>
<li>AppBarはheader的なもののようだ</li>
<li>GridViewでGrid表示ができる</li>
<li>ListViewのような動的な要素をColumnのchildrenとして表示する場合、Expandedで囲わないとエラーが出る
<ul>
<li>sizeの計算がうまくいかない場合があるようだ</li>
</ul>
</li>
</ul>
<h1 id="画面の遷移">画面の遷移</h1>
<ul>
<li>Navigatorを使う。Navigator.push(),のような感じで呼び出せるようだ
<ul>
<li>webのようにURLではなく、遷移先のWidgetを投げ込む形</li>
</ul>
</li>
</ul>
<h1 id="dartメモ">Dartメモ</h1>
<ul>
<li>A..B()のような構文がある。<code>カスケード表記</code> と呼ぶらしい。(cascades notation)
<ul>
<li>これを使うと、Aに対する操作が複数ある時、Aを省略できる。メンバ変数への代入とかもできるので初見でびびった</li>
</ul>
</li>
<li>@override
<ul>
<li>interfaceの関数をoverloadしているという宣言</li>
</ul>
</li>
<li>const
<ul>
<li>finalより強い。コンパイル時に値がわかるものにしか使えない</li>
</ul>
</li>
<li>required
<ul>
<li>必須の引数</li>
</ul>
</li>
<li>名前付き引数がある</li>
<li>folder構成
<ul>
<li>推奨なものはないっぽい。MVVMやRedux（こっちにもあるんだ）など、採用するアーキテクチャによっても変わりそう</li>
</ul>
</li>
<li>testの叩き方</li>
<li>dataはどこに永続化するの
<ul>
<li>nativeだとどうなる？</li>
</ul>
</li>
<li>path_provider
<ul>
<li>プラットフォームによってアプリのディレクトリが違ってくるから、そういう違いを吸収してくれる
<ul>
<li>osのpathデリミタが違うのを吸収してくれるみたいな話でおもろかった。確かに必要だよな〜</li>
</ul>
</li>
</ul>
</li>
<li>part
<ul>
<li>fileを分けるけど、拡張ファイル的な概念。Cのincludeっぽい</li>
</ul>
</li>
<li>package_info_plus
<ul>
<li>licenseをまとめて表示してくれる便利package</li>
</ul>
</li>
</ul>
<h1 id="reactからの差分">Reactからの差分</h1>
<ul>
<li>全体的に書きづらいReactのclassコンポーネントを書いてる気持ちになる
<ul>
<li>が、これは普段React+TypeScriptに慣れているからなので当たり前</li>
</ul>
</li>
<li>Reactを参考にしているからか、Reduxがflutterにもあったり、setStateというまんまな関数があったりする</li>
<li>widgetの階層をまたいだときのデータのやり取りどうするの? みたいな課題感はwebフロントと一緒</li>
<li>riverpodはだいぶややこしい書き味に見えたが、最初にreduxを見た人も同じこと思ってそう
<ul>
<li>変更をwatchする書き方がReactと違うだけと思ったらまぁそういうもんかと腹落ちした</li>
<li>Flutterでも単方向データフロー+immutableなデータを使う、という文化は推奨されている雰囲気</li>
</ul>
</li>
<li>frontではSWRやTanStackQueryのように宣言的に寄せる文化があるが、ネイティブアプリが追従するかは気になる
<ul>
<li>似たような仕組みはありそうだったが深く掘り下げていない</li>
</ul>
</li>
<li>SSR、SSGのような文化は必要ないので、そこで差分が出てきそうだ</li>
</ul>
<h1 id="riverpodなどを用いたデータ管理">Riverpodなどを用いたデータ管理</h1>
<ul>
<li>FlutterでもSSOTの考え方がある。Reactのstateみたいなのがあるしな</li>
<li>RiverpodはReactのcontext（っぽい）仕組みで、providerを用意してそれを必要なcomponentがwatchする形になっている
<ul>
<li>このinterfaceを守ればwatchする側は裏側を知らなくて良い</li>
<li>firebaseでもなんでもこの仕組みで扱える</li>
</ul>
</li>
<li>見た目はちょっと慣れないと使いづらそうだったので要素振り</li>
</ul>

Flutter触ってみたのでメモ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#dockerdesktop%E3%81%AE%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3">DockerDesktopのアーキテクチャ</a>
<ul>
<li><a href="#runc%E3%83%A1%E3%83%A2">runcメモ</a></li>
<li><a href="#containerd%E3%83%A1%E3%83%A2">containerdメモ</a></li>
</ul>
</li>
<li><a href="#%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E4%BD%9C%E3%82%8B%E3%82%88">コンテナ作るよ</a></li>
<li><a href="#%E3%83%A1%E3%83%A2">メモ</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p><a href="https://zenn.dev/akb428/articles/49e51d4db36896">Moby(Docker)をビルドしてruncとcontainerdを単体で動かしてコンテナの基礎を理解する</a> .
という記事と、
<a href="https://litchipi.github.io/series/container_in_rust">Writing a container in Rust</a> .
という記事があったのでやって感想をまとめる</p>
<p>昔Rustでコンテナを作ってみようとして挫折した（cgroupやnamespaceの切り方がちゃんとわからなかった...）のでリベンジしたい、というのがモチベーション
最初の記事ではDockerのアーキテクチャ（低レベルランタイム、高レベルランタイム）について学び、二つ目の記事ではコンテナ自体の仕組みと 　
それを実現するためのRustのAPIを知りたい</p>
<p>完了した時にはruncとcontainerdの動かし方がわかっていて、Rustでcontainerを作成する方法も学べているはず</p>
<h1 id="dockerdesktopのアーキテクチャ">DockerDesktopのアーキテクチャ</h1>
<p>moby->containerd->runcの順に降りていく感じ</p>
<ul>
<li>containerdは高レベルランタイムで、imageの管理やruncのような低レベルのランタイムの実行を行う
<ul>
<li>gRPCで外からリクエストを受け付けるのもこいつ</li>
<li>k8sもfargateもこれ使ってる</li>
</ul>
</li>
<li>runcは実際にnamespaceやcgroupを使ってコンテナを作成する役目</li>
<li>runcより下は、MacやWindowsでも動かせるように「LinuxKit」としてLinuxKernelが入っていて、その下にQEMUとかHyperKitがいる</li>
</ul>
<h2 id="runcメモ">runcメモ</h2>
<ul>
<li>runc specで仕様ファイルが生成される（config.json）
<ul>
<li>capabilityとかnamespaceが設定されてる</li>
<li>mount先のpathやprocのpathのどこを使うかとかも</li>
<li>rootがどこかも書いてあって、デフォルトではrootfsになっている。なのでmkdirでcurrentにrootfs作ると動く</li>
</ul>
</li>
<li>argsを作ったhelloに置き換えて実行してみる（READMEではshをbusyboxで持ってくるらしい）
<ul>
<li>helloは実行前にrootfs/binに移動しておく</li>
</ul>
</li>
<li>隔離されているか確認するためにls作ったりstrace走らせたりする</li>
</ul>
<h2 id="containerdメモ">containerdメモ</h2>
<ul>
<li>操作はctrコマンドで行う
<ul>
<li>これはcontainerdのcli</li>
<li>interfaceはだいぶdockerコマンドに近い感じ
<ul>
<li>imageのpullとかできるよ</li>
</ul>
</li>
</ul>
</li>
<li>nerdctlというdocker互換のコマンドがあり、これでdockerっぽい操作ができる</li>
</ul>
<h1 id="コンテナ作るよ">コンテナ作るよ</h1>
<ul>
<li>structopt
<ul>
<li>clapをバックエンドにしたargパーサ</li>
<li>///でコメント打つとそれがmessageになってくれるっぽい?</li>
<li>#[structopt]でshortやlongのoptionを設定できる</li>
</ul>
</li>
<li>config引数のargvをCStringにしているのは、execveのsyscallを呼ぶ時に便利だからだそうな</li>
<li>nix使ってunameやhostを取得している
<ul>
<li>linuxのkernelのversionの検査がいるため。Macでも動くんだけど互換があるのか...?</li>
</ul>
</li>
<li>child processを生やすぞ
<ul>
<li>IPC(Inter process communication)を使う</li>
<li>通信にはunix domain socketsを使う。nginxとphp-fpmを繋ぐ時に使ったりするアレです</li>
<li>socket関連の関数とかもnixに生えてる
<ul>
<li>rustフレンドリーな*nixシステム関数群だそうで</li>
</ul>
</li>
<li>nixのSockFlag::SOCK_CLOEXECがMacだと動かなそう(target_osに記載がないので)</li>
</ul>
</li>
</ul>
<h1 id="メモ">メモ</h1>
<ul>
<li>rustのmod.rsを置く方法は古いらしい
<ul>
<li>hogeディレクトリ切ったら、hoge.rsを置いて、その中でhoge/fugaをmodすることで依存を解決するみたい</li>
</ul>
</li>
<li>RawFd、はファイルディスクリプ他。unixでしか使えない</li>
</ul>

MobyとRustで作るコンテナをやる

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#vite%E3%83%A1%E3%83%A2">viteメモ</a></li>
<li><a href="#reactlocation%E3%83%A1%E3%83%A2">ReactLocationメモ</a></li>
<li><a href="#tailwindcss%E3%81%A8css%E3%83%A1%E3%83%A2">tailwindcss(とCSS)メモ</a></li>
<li><a href="#laravel%E3%81%AE%E8%AA%8D%E8%A8%BC%E8%AA%8D%E5%8F%AF">Laravelの認証認可</a></li>
<li><a href="#%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%82%E3%82%8C%E3%81%93%E3%82%8C">セキュリティあれこれ</a></li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<ul>
<li>Viteってなに</li>
<li>ReactLocation使ってみる</li>
<li>ReactHooksForm使ってみる</li>
<li>ReactQuery使ってみる</li>
<li>tailwind使ってみる</li>
<li>laravelと組み合わせた認証・認可やってみる</li>
</ul>
<h1 id="viteメモ">viteメモ</h1>
<ul>
<li>postcssにデフォルトで対応しているので、tailwindcssの導入も簡単</li>
</ul>
<h1 id="reactlocationメモ">ReactLocationメモ</h1>
<ul>
<li>routeの指定はobject</li>
<li>loaderというattributeをrouteが持ってて、非同期のapi取得などを待機できる
<ul>
<li>これで読み込み終わってから遷移というのができそう</li>
<li>遷移中に画面が白くなるような気もするが...これはなんか書いてあった気がするな</li>
</ul>
</li>
<li>useNavigateを使うと、関数呼び出しでlinkの移動ができる</li>
<li>loginされていない時にlogin画面に遷移はどう作る？
<ul>
<li>user情報を参照して、持っていなければloginへ飛ばすようなNavigateを作る</li>
<li>でやってみたけど微妙そう
<ul>
<li>dataloaderかoutletが必要そう?</li>
<li>Outletはデフォルトのコンポーネントで、階層を作るためだけに使われるっぽい（通常そのpathをそのまま下に流す？）</li>
</ul>
</li>
<li>react-queryでuserを取得しているのがそもそも微妙そうな予感</li>
<li>必ず通るrootでuserエンドポイントを叩いて、帰って来なかったらlogin帰ってきたなら元のpath、というようにすれば良い気がしてきたが...
<ul>
<li>ダメだった</li>
</ul>
</li>
<li>初回のアクセスで必ず通るcomponentを作れば良いんでは?</li>
<li>調査中</li>
</ul>
</li>
</ul>
<h1 id="tailwindcssとcssメモ">tailwindcss(とCSS)メモ</h1>
<ul>
<li>postcss必要</li>
<li>バンドルサイズがデカくなるのでpurgeが必須っぽい?</li>
<li>will-cahngeは要素がどうやって更新されるかを示す。filterとかtransitionとかみたいだけど、filterはdocumentにない
<ul>
<li>しかしviteでセットアップしたprojectのcssに入ってた</li>
</ul>
</li>
<li>labelのforにidを当てると、labelクリックでidの要素をクリックしたことにできる</li>
<li>role属性はアクセシビリティのためにあるようだ</li>
</ul>
<h1 id="laravelの認証認可">Laravelの認証認可</h1>
<ul>
<li>普通のpassword認証がやってみたい
<ul>
<li>というか仕組みが見たい</li>
</ul>
</li>
<li>Guardがリクエストごとにユーザを認証する方法を提供する
<ul>
<li>例えばSessionとCookieでの検証であればセッションガード</li>
</ul>
</li>
<li>laravelのbreezeというスキャッフォルドをまず試す
<ul>
<li>composerでinstallしたあと、<code>php artisan breeze:install api</code> でapi用のスキャっフォルドが作られる
<ul>
<li>apiをつけないとresorucesのjsに諸々作られてしまう</li>
</ul>
</li>
<li>実行すると
<ul>
<li>corsの設定に許可されるoriginが追加される
<ul>
<li>これはenvにFRONTEND_URLを記載していないといけない</li>
</ul>
</li>
<li>routes/にauth.phpが追加されて、色々endpointが生えてる</li>
<li>AuthServiceProviderも書き変わっている</li>
</ul>
</li>
</ul>
</li>
<li>guest middlewareは何をしているか
<ul>
<li>RedirectIfAuthenticatedのmiddlewareを通過している
<ul>
<li>認証済みだったらばRouteServiceProvider::HOMEにredirectする
<ul>
<li>これはデフォルトだと/home</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>UserにはHasApiTokenトレイトのuseが必要</li>
<li>validateのconfirmed、同じparamの_confirmationと同値の必要がある
<ul>
<li>password_confirmationみたいなね</li>
</ul>
</li>
<li>sanctum
<ul>
<li>configに設定が生えてる。SPA認証なども行える認証用ライブラリ</li>
<li>FRONTEND_URLやAPP_URLの設定から、許可するdomainを決定してるっぽい</li>
<li>csrf-cookieって何？
<ul>
<li>どうやってcsrfの判定通すんだ？</li>
<li>responseで帰ってきたXSRF-TOKENをX-XSRF-TOKENに詰めて渡せばいいみたいだけども</li>
<li>見えないと思ったけど、artisanのroute一覧表示で確認できる
<ul>
<li>vendorを見ると、SanctumServiceProviderで登録がなされてる（defineRoutesがそう）</li>
<li>laravelの直下にあるから、publishすると勝手に入るものなのかも
<ul>
<li>publishしてるProviderがSanctumServiceProviderだもんなぁ</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>SANCTUM_STATEFUL_DOMAINSに<code>localhost:5173</code>入れないとfromFrontendがtrueにならん</li>
<li>documentにport含むならそれをdomainに書きたまえよってあった...</li>
</ul>
</li>
<li>$table->morphs('string')
<ul>
<li>string_id（BIG int）と、string_type（varchar）を生成するshorthandっぽい</li>
</ul>
</li>
<li>はまったところメモ
<ul>
<li>SANCTUM_STATEFUL_DOMAINSの指定が必要だった
<ul>
<li>FRONTEND_URL設定してるから平気やろwとか思ってたらそんなこたぁなかった</li>
<li>FRONTEND_URLをhttp://localhost:5173にしてるから大丈夫だろ、とか思ってたけど、localhost:5173の指定が必要だったみたい</li>
</ul>
</li>
<li>SESSION_DOMAINを指定していたら、XSRF_TOKENがjsからさわれなくて困った
<ul>
<li>指定を外すか、単にlocalhostとしたら直った（port番号をつけてしまっていたのが良くなかったみたい）</li>
<li>SESSION_DOMAINは、本来サブドメインが一致するサイト間でsessionを共有する仕組みみたいだ</li>
</ul>
</li>
<li>decodeURIComponentで、sanctum/csrf-cookieで取得したCookieを変換しないとtokenの認証通らなかった</li>
<li>paddingで入っている==とかが引っかかる</li>
<li>defaultではCookieは送られないので、fetchでauth:sanctum通す場合、mode: corsとcredentials:includeの設定が必要</li>
</ul>
</li>
</ul>
<h1 id="セキュリティあれこれ">セキュリティあれこれ</h1>
<ul>
<li>https://www.slideshare.net/ockeghem/phpconf2021spasecurity
<ul>
<li>laravel sanctumの話が乗ってる</li>
</ul>
</li>
<li>ヘッダにトークンを付与する場合、CORS不備の影響は少ない</li>
<li>Cookieを伴う場合、
<ul>
<li>Access-Control-Allow-Credentials: true</li>
<li>Access-Control-Allow-Origin: "サイトのorigin"</li>
<li>の指定が必要</li>
</ul>
</li>
<li>JWTはOpenID ConnectのID運搬ように作られたが、セッションとして使われる例が多発
<ul>
<li>これだとセッション飛ばしてログアウトさせるということができない</li>
<li>タイムアウトと、リフレッシュトークンを使う</li>
<li>1時間ぐらいでJWTをタイムアウトするようにしておく（Firebase Authenticationのデフォルトが1時間）</li>
</ul>
</li>
<li>sanctumのトークン
<ul>
<li>APIトークンをDBに埋めるのでステートフル</li>
<li>Authorizationヘッダにトークンを埋めて認証認可</li>
<li>SanctumのSPA認証ではトークンを利用しない
<ul>
<li>Cookieベースのセッション認証サービスを利用する</li>
</ul>
</li>
</ul>
</li>
<li>JWTのメリットは認可サーバの負荷軽減、スケールアウトのしやすさ
<ul>
<li>デメリットは即時ログアウトができない</li>
<li>Chatworkは実際のオペレーションで停止するのも30分かかるだろうということで、30分設定のJWTで運用している</li>
</ul>
</li>
<li>ステートフルなセッションのメリットはすぐにログアウトできる、が
<ul>
<li>デメリットとしてスケールしづらい、セッションDBがボトルネックになるかも</li>
</ul>
</li>
<li>Web APIの脆弱性は、Content-Typeをapplication/jsonにしていると防ぎやすい</li>
<li>DOM周りにエスケープしない文字列を表示する処理は基本的に危ない</li>
<li>SPAでヘッダにトークンをつける場合は、CSRF攻撃はできない</li>
<li>Cookieはcrendentialとも呼ばれる
<ul>
<li>Cookieの情報でもって認証などを行うことがあるため</li>
</ul>
</li>
<li>CORSリクエストでは通常cookieが付与されない
<ul>
<li>credentials: 'include'にすると付与される</li>
<li>Access-Control-Allow-Credentials: trueで、Cookieを必要とするアクセスを明示的に許可している</li>
</ul>
</li>
<li>Simple RequestではPreflightが不要
<ul>
<li>ブラウザがデフォルトで送信できるRequest（formによるもの）とかはSimpleRequest
<ul>
<li>formから発生するGETとPOST</li>
</ul>
</li>
<li><code>a</code>, <code>img</code>, <code>script</code> から発生するRequestもSimpleRequest</li>
</ul>
</li>
<li>Fetchのmodeには五種類ある
<ul>
<li>navigate</li>
<li>no-cors</li>
<li>cors</li>
<li>same-origin</li>
<li>websocket</li>
<li>真ん中三つはfetchの引数に指定可能</li>
</ul>
</li>
<li>EnsureFrontendRequestsAreStatefulは何やってるの？
<ul>
<li>configureSecureCookieSessionsを呼ぶ。以下の二つがconfigに設定される
<ul>
<li>'session.http_only' => true,</li>
<li>'session.same_site' => 'lax',</li>
</ul>
</li>
<li>ちなみにcookieがhttp_onlyかどうかとかはdevtoolから見れるよ</li>
<li>Pipelineで認証を通してそうだけど、Pipelineはなに？
<ul>
<li>それぞれのステップで起こった例外をキャッチしてresponseにしてくれるみたい？</li>
</ul>
</li>
<li>webで使う一部のmiddlewareを呼び出している
<ul>
<li>\App\Http\Middleware\EncryptCookiesは、Cookieの暗号化</li>
<li>CsrfTokenのverifyとかもそう</li>
</ul>
</li>
</ul>
</li>
<li>app()を受けて、sendにrequestを指定して、throughでfromFrontendがtrueなら、
<ul>
<li>'sanctum'をtrueにして、</li>
<li>sanctum.middleware.encrypt_cookiesを設定して、</li>
<li>\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,を設定して</li>
<li>\Illuminate\Session\Middleware\StartSession::classも設定して、
<ul>
<li>classを投げると自動でinstantiateしてるっぽい挙動</li>
<li>instaintiateしてhandleが呼ばれる?</li>
<li>見た目はmiddlewareっぽい、引数と$nextを受ける</li>
<li>Illuminate\Pipeline\Pipelineを読むと、method変数に定義されている関数をstepsに入れたものに対して呼び出すみたいだ
<ul>
<li>デフォルトではhandleが呼ばれる</li>
<li><code>$this->{$this->method}()</code> こんな呼び出しできるんだなぁ</li>
</ul>
</li>
</ul>
</li>
<li>sanctum.middleware.verify_csrf_tokenを設定して</li>
<li>$next($request)を呼び出す</li>
</ul>
</li>
<li>fromFrontendはなに？
<ul>
<li>sanctum.statefulに指定したdomainに一致するrequestかどうかを確認している</li>
</ul>
</li>
<li>SubstituteBindingsは何やってるの？
<ul>
<li>Routeのpathにモデルのbindingをしているみたいだ</li>
</ul>
</li>
<li>laravelのeventとlistener
<ul>
<li>registerでevent(new Registerd($user))があるけどこれなに</li>
<li>誰がサブスクライブしてるんだ？
<ul>
<li>event:listをartisanで叩くと一覧が見れる</li>
<li>EventServiceProviderに登録があって、デフォルトだとメールが飛ぶっぽい</li>
</ul>
</li>
</ul>
</li>
</ul>

Reactサンドボックス作ってあれこれやる

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E3%81%AA%E3%81%AB%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">なにを学ぶか</a></li>
<li><a href="#1%E7%AB%A0%E3%83%A1%E3%83%A2">1章メモ</a></li>
<li><a href="#2%E7%AB%A0%E3%83%A1%E3%83%A2">2章メモ</a></li>
<li><a href="#3%E7%AB%A0%E3%83%A1%E3%83%A2">3章メモ</a></li>
<li><a href="#4%E7%AB%A0%E3%83%A1%E3%83%A2">4章メモ</a></li>
<li><a href="#5%E7%AB%A0%E3%83%A1%E3%83%A2">5章メモ</a></li>
<li><a href="#6%E7%AB%A0%E3%83%A1%E3%83%A2">6章メモ</a></li>
<li><a href="#%E8%AA%9E%E5%BD%99%E3%83%A1%E3%83%A2">語彙メモ</a></li>
<li><a href="#%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A">振り返り</a></li>
</ul>
<h1 id="なにを学ぶか">なにを学ぶか</h1>
<ul>
<li>パフォーマンスチューニングの流れが、どの手順で行われることがあるのか説明できる</li>
<li>nginxの設定の何を変更すべきかわかっている</li>
<li>MySQLのindexをいつどういう基準で使えば良いかわかっている</li>
</ul>
<h1 id="1章メモ">1章メモ</h1>
<ul>
<li>ボトルネックになりがちなのはCPU,メモリ、ディスクIO,ネットワークIO</li>
<li>データの入出力の外側からみていくのが大事</li>
</ul>
<h1 id="2章メモ">2章メモ</h1>
<ul>
<li>負荷試験を行うClientは対象のサーバの外に出すこと
<ul>
<li>なるべく本番のアーキテクチャに近づけるのが肝要</li>
</ul>
</li>
<li>プロファイルの解像度には適切な値がある。例えば5秒ごとにメトリクスを取ると、1秒で変化して1秒で戻るような現象をキャッチできない
<ul>
<li>この足りていない状態は解像度が足りないとかいう</li>
<li>解像度を上げると負荷が上がるので調整が必要</li>
</ul>
</li>
<li>コードのどこで時間が掛かっているかを測定するものを「ラインプロファイラと呼ぶ」</li>
</ul>
<h1 id="3章メモ">3章メモ</h1>
<p>実際にprivate-isuを動かすパート。構築された環境に学びがあるので書いていく(isucon関係ない内容もあるけど)<br>
全体の内容としてはログなどからアプリの情報を集める工程について述べられている</p>
<ul>
<li>docker-php-ext-install は、installと有効化を行うコマンド</li>
<li>peclで入れたものはdocker-php-ext-enableで有効化する必要がある</li>
<li>composer install --no-devは本番環境向け（--devオプションもある）
<ul>
<li>require-devにあるpackageのinstall及び、autoload-devをskipする</li>
</ul>
</li>
<li>nginxのlog_formatはjsonにした方が見やすくて良い
<ul>
<li>escape=jsonを指定すると、ダブルクォーととかが登場した時に適切にescapeしてくれる</li>
<li>access_log /var/log/nginx/access.log json;はserverの中に書かないとデフォルトのlogと重複して出力されていた</li>
</ul>
</li>
<li>alpというjsonやLTSV形式のファイルをパースできるツールがある。Go製
<ul>
<li>alp jsonを叩くとデフォルトで、method,uri,status,body_bytes,response_timeを集計してくれる</li>
</ul>
</li>
<li>ab（Appach Bench）というコマンドがあるそうな。Macの場合はデフォルトで入ってる</li>
<li>負荷試験ごとにlogファイルを分けて、それぞれをalpで解析する流れが良いらしい。
<ul>
<li>アクセスログのローテーションってやつ</li>
</ul>
</li>
<li>topのCPU表記は、%Cpu(s)が全CPUコアを100としたもので、%CPUは1コアを100としたもの</li>
<li>MySQLのボトルネック解析
<ul>
<li>my.cnfのlong_query_timeは、指定した秒数以上のqueryを出す。0にすると全部出る</li>
<li>長いのがダメかと思いきや、回数が多すぎてもダメなのでそういう意味でもパフォチューの時は全部出すんだとか</li>
</ul>
</li>
<li>mysqlのslowログは、mysqldumpslowコマンドを使うと、実行時間の長いクエリから順に表示してくれる
<ul>
<li>呼び出し回数も見れて良い</li>
</ul>
</li>
<li>SHOW CREATE TABLE {テーブル名}で、そのテーブルを作るのに必要なSQLが見れる</li>
<li>indexのないcolumnをwhereの条件に入れるとfull scanが走る</li>
<li>EXPLAinで
<ul>
<li>keyがnull、indexなし</li>
<li>rowsの数が対象の行数</li>
</ul>
</li>
<li>topで全体の負荷でどこが重いかわかるといいなぁ</li>
<li>並列度は、CPU数の倍ぐらいに設定して良いこともある
<ul>
<li>これはidleになるprocessがいると勿体無いため。5倍ぐらいにした例もあるとか</li>
</ul>
</li>
</ul>
<h1 id="4章メモ">4章メモ</h1>
<ul>
<li>skip</li>
</ul>
<h1 id="5章メモ">5章メモ</h1>
<ul>
<li>MySQLのqueryの最後を\Gにするか;にするかで、queryの結果の表示が縦と横で変わる</li>
<li>ExtraにUsingFilesortとあると、sort処理が走っている
<ul>
<li>post_idとcreated_atの複合indexを作ると、sortする処理が省ける</li>
<li>backward scanと出る場合は、昇順indexを逆向きに読んでいるということなので、降順indexに変えると改善する
<ul>
<li>index指定で <code>add index xxx(column DESC); </code>とすれば良いようだ</li>
</ul>
</li>
<li>Extraがnullになると余計な条件が減る</li>
<li>セカンダリインデックスは、プライマリインデックス</li>
<li>indexのイメージはsort済みのDB</li>
</ul>
</li>
<li>クラスターインデックス
<ul>
<li>プライマリインデックスのツリー構造の先にデータがあ含まれている</li>
<li>プライマリインデックス以外は全部セカンダリインデックスとよび、ツリー構造の先にプライマリキーが含まれている</li>
</ul>
</li>
<li>order by狙いのindexにしていると、日付の新しいものから探される。新しいものの方がアクセスされる可能性が高いので、読み込んだ行数が減ることが期待できる</li>
<li>explainの結果、using indexとなっているとindexが参照される</li>
<li>indexのアンチパターン
<ul>
<li>増やしすぎると更新が重くなる</li>
</ul>
</li>
<li>全文検索のindex
<ul>
<li>n-gramや形態素解析によるindexの作成が可能</li>
<li>通常LIKE検索では%や_の前しか見れない。前方一致じゃないとindexが効かないんじゃわ</li>
</ul>
</li>
<li>N+1はjoinや、非正規化で解消できる</li>
<li>FORCE INDEXでどのindexを使うか指定することができる</li>
<li>STRAIGHT JOINを使うとqueryの順番にindexが使われる</li>
</ul>
<h1 id="6章メモ">6章メモ</h1>
<ul>
<li>リバプロの意義とnginxについて
<ul>
<li>リバースプロキシは静的ファイルの配信を行なってApp鯖の負荷を軽減したり、TLS終端したりできる</li>
<li>nginxの設定は複数のserverの設定を行うことができて、それはserver{}の中に書く</li>
<li>locationにpathを書くことで静的ファイルが配信できる
<ul>
<li>root $pathで対象のpathをfullpathで指定する</li>
<li>expiresの指定でファイルをcacheするようだ</li>
</ul>
</li>
<li>proxy_set_header Host $host;とすることで、リバプロに来たヘッダを流せる</li>
<li>gzipによる圧縮が行えるかは、リクエストのHTTPヘッダにAccept-Encoding: gzipがあるかどうからしい
<ul>
<li>最近のブラウザなら必ず入っているんだとか</li>
</ul>
</li>
<li>nginxにもモジュールがあり、ngx_http_gzip_static_moduleを使うと事前に圧縮したファイルを使えるようになるんですって</li>
<li>application鯖で圧縮できるならその方が良い</li>
<li>keepaliveの設定で、受け付ける最大のrequest数を指定できる</li>
<li>try_filesは左から順に見ていってあれば使う</li>
<li>query stringに毎回違う値を入れてcacheを破棄できる
<ul>
<li>これはlaravel-mixとかがやってる</li>
</ul>
</li>
<li>「jpegやpngは既に圧縮されているので二重圧縮しない」ように注意</li>
</ul>
</li>
</ul>
<h1 id="語彙メモ">語彙メモ</h1>
<ul>
<li>水平スケール・垂直スケール
<ul>
<li>インスタンスのスペックを上げるのが垂直。数を増やすのが水平</li>
</ul>
</li>
</ul>
<h1 id="振り返り">振り返り</h1>
<ul>
<li>パフォーマンスチューニングの流れが、どの手順で行われることがあるのか説明できる
<ul>
<li>まずは計測</li>
<li>その後ボトルネックを一つずつ潰していく
<ul>
<li>時間のかかっている箇所は、CPUの使用率の高いプロセスだったり、responseまでの時間だったりから見つける</li>
</ul>
</li>
</ul>
</li>
<li>nginxの設定の何を変更すべきかわかっている
<ul>
<li>gzip圧縮の有無、log_formatのjson化、staticファイルの配信について覚えた</li>
</ul>
</li>
<li>MySQLのindexをいつどういう基準で使えば良いかわかっている
<ul>
<li>where句で指定するものにはindexを貼ると良い
<ul>
<li>貼りすぎると逆にinsert時の性能が低下する</li>
</ul>
</li>
<li>indexはsort済みのtableを作るようなもの、という例えがわかりやすかった
<ul>
<li>created_atのような日付を指定するとorder byが高速になるほか、降順でindexしておくと最新のものほど早くアクセスされるので走査対象が減ることを覚えた</li>
</ul>
</li>
</ul>
</li>
</ul>

ISCON本を読んだ

低レイヤを知りたい人のためのCコンパイラ作成入門を読んだ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E4%BD%95%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">何を学ぶか</a></li>
<li><a href="#3%E7%AB%A0">3章</a></li>
<li><a href="#5%E7%AB%A0">5章</a></li>
<li><a href="#6%E7%AB%A0">6章</a></li>
<li><a href="#%E3%83%A1%E3%83%A2">メモ</a>
<ul>
<li><a href="#%E9%83%A8%E5%88%86%E5%9E%8B">部分型</a></li>
<li><a href="#%E5%85%B1%E5%A4%89%E6%80%A7%E3%81%A8%E5%8F%8D%E5%A4%89%E6%80%A7">共変性と反変性</a></li>
<li><a href="#%E5%9E%8B%E3%82%AF%E3%83%A9%E3%82%B9">型クラス</a></li>
</ul>
</li>
</ul>
<h1 id="何を学ぶか">何を学ぶか</h1>
<p>TypeScriptは普段から業務でも使う言語で、また個人としても好きな言語なので、より深い知識をつけるために購入した<br>
結論から言うと非常に良い本で、全ての章で学びがあった。著者の知識量に圧倒されるばかりである</p>
<p>TypeScriptを書く人はみんな読んだ方がいいんじゃないかと思った</p>
<p>特によかった章ごとにまとめる。そのほかはメモとして最後にまとめる</p>
<h1 id="3章">3章</h1>
<p>常に扱うことになるオブジェクトの知識についての章<br>
interfaceとtype定義での型定義と、そのどちらを使うべきか（基本はtypeで問題ないとされていた）について指針があったり<br>
インデックスシグネチャの扱いづらさについても触れられていてよかった
動的な連想配列を扱うときは素直にMapを使おう</p>
<p>noUncheckedIndexedAccessが有効になれば防げるから～と思っていたけれど、実際扱いづらいところはあるのでそもそも使わない方法を考えるのがよいと学んだ<br>
TypeScriptはJavaScriptのランタイムの挙動を捻じ曲げたりすることはできない</p>
<p><code>Object.keys</code> がstring[]しか返さないのなんでやんと思っていたが、あれはそもそもstringしか受け付けないのね...</p>
<p>分割代入 <code>[, , three, , five] = [1,2,3,4,5]</code> のようにできると知らなかった。今までアンスコに逃がしていた</p>
<h1 id="5章">5章</h1>
<p>クラスについての章</p>
<p>クラスは全然使ったことがなかったので、静的初期化ブロックとかnewシグネチャとか知らなかった</p>
<p>他にもprivateがTypeScript独自で、後から#によるprivate変数がJavaScript側に生えたのはわかっていたが、JSON.stringifyに通すと後者が消えるのは知らなかった<br>
なんとなく知らないとハマりそうな挙動に感じる</p>
<p><strong>class宣言は、型と変数を同時に定義する構文</strong> と説明されていたのが非常にわかりやすくてよかった。classの定義が型にもなっててややこしいなぁと思っていたので</p>
<p>実際に使う機会は少なそうだったが、ここで説明されていた内容は多分初見だと面食らうタイプのものが多いように感じたので、<br>
読みごたえがあり面白かった</p>
<h1 id="6章">6章</h1>
<p>TypeScriptの型システムについて学ぶ章。一番面白かった<br>
共変、反変の概念は難しかったのでメモに</p>
<p>wideningの挙動について詳しいのがうれしい</p>
<p>直和型がunion型だと思っていたけど厳密には違うらしい。タグ付きUnionで調べるとCにもあるのがおもろいな（タグ付き共用体）</p>
<p>switchのdefault節はしょってもエラーが出るの確かに。今までneverな変数に代入していたのは無駄だった...<br>
tag付きUnionを絞り込む場合、default節自体が有用じゃなさそうだ</p>
<p>keyofやlookupのような主に型パズルで見るあれについても説明がある（T[K]をlookup型というのは知らなかった）</p>
<p>objectリテラルで、keyが必ずstringで扱われるの知らなかった。どおりでObject.keysがstring[]しか返さないわけだよ...<br>
TypeScriptはランタイムの挙動は変えないんでしたね</p>
<p>stringを含むUnion型Tに、stringのみである制約をつけたいとき、T &#x26; stringでできる。覚えとくといいことありそう</p>
<h1 id="メモ">メモ</h1>
<h2 id="部分型">部分型</h2>
<p>簡単に書くならクラスAを継承したクラスBがあるとき</p>
<h2 id="共変性と反変性">共変性と反変性</h2>
<p><code>引数は反変であり、戻り値は共変である必要がある</code></p>
<p>この概念が本を読んだだけではまだしっくりこなかったので自分でも調べてみた<br>
「～である必要がある」というより、この方が型安全である、という感じっぽい？<br>
ある型Aが他の型Bの部分型である、ということについての理解が自分の中で言語化できていなかったので、それを学ぶよい機会になった</p>
<p><a href="https://ja.wikipedia.org/wiki/%E5%85%B1%E5%A4%89%E6%80%A7%E3%81%A8%E5%8F%8D%E5%A4%89%E6%80%A7_(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6)">wiki</a>共変、反変の概念がわかる</p>
<p>ただなんでサブクラスでは、引数が反変の方が型安全なのかいまいち理解しきれなかった</p>
<h2 id="型クラス">型クラス</h2>
<p>型を学習していると型クラスという単語を見かけるが、どうやらTypeScriptにはなく、Rustにはあるらしい（traitがそう）<br>
いまいち概念がわかっていないという前提でざっくり書く、<br>
インスタンス化すると型になるのが型クラスらしい。クラスがインスタンス化するとオブジェクトになるのと近いイメージ<br>
型の集合を定義するものというか、IntとFloatが属するNumという型クラスが作れて、Numには算術演算の関数が生えており、IntとFloatどちらにも適用可能<br>
これだけ書くと基底クラスっぽさがあるな...いやでも型「クラス」なので間違いではないのか<br>
ここで基底となった型クラスの制約を満たす型を定義できるということでね</p>

プロを目指す人のためのTypeScriptを読んだ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E3%81%AA%E3%81%AB%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%8B">なにを学ぶか</a></li>
<li><a href="#transaction%E5%88%86%E9%9B%A2%E3%83%AC%E3%83%99%E3%83%AB">transaction分離レベル</a></li>
<li><a href="#acid%E7%89%B9%E6%80%A7">ACID特性</a></li>
<li><a href="#innodb%E3%81%AErepeatable-read%E3%81%AElock">InnoDBのREPEATABLE READのlock</a></li>
<li><a href="#%E8%A1%8C%E3%83%AD%E3%83%83%E3%82%AF">行ロック</a></li>
<li><a href="#%E3%83%A1%E3%83%A2">メモ</a></li>
<li><a href="#%E5%8F%82%E8%80%83%E6%96%87%E7%8C%AE">参考文献</a></li>
</ul>
<h1 id="なにを学ぶか">なにを学ぶか</h1>
<p>transaction分離レベル、およびそれを実現するlockの挙動について知見を深めたい</p>
<p>分離レベルと、それぞれどういう読み取りが起きるのかまではわかったが、<br>
InnoDBではphantom readが起きないというのを見かけて詳しく知りたくなった<br>
lockの挙動を覚えることで、デッドロックが発生したときの原因調査ができるようになってほしい</p>
<p>参考文献が非常に参考になったので、後は実務でぶつかったら都度確認して対応みたいな感じでよいかもしれない</p>
<h1 id="transaction分離レベル">transaction分離レベル</h1>
<p>transaction分離レベルはSQL標準で定められたもので、以下の四つがある</p>
<ul>
<li>
<p>read uncommited</p>
<ul>
<li>分離レベルが一番弱い。ダーティリード、ファジーリード、ファントムリードが起きる</li>
</ul>
</li>
<li>
<p>read commited</p>
<ul>
<li>ファジーリード、ファントムリードが起きる。Postgresのデフォルトはこれ</li>
</ul>
</li>
<li>
<p>repeatable read</p>
<ul>
<li>ファントムリードが起きる。MySQL(というかInnoDB?)のデフォルトはこれ</li>
<li>ただしInnoDBではファントムリードを防ぐようになっている
<ul>
<li>MVCC(Multi version concurrency control)という仕組みで何とかしているらしい
<ul>
<li>lock取得時のsnapshotから読み取りをするので、ファントムリードが起きないそうだ</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>
<p>serializable</p>
<ul>
<li>各種リード現象は起きないが、性能が低い</li>
</ul>
</li>
<li>
<p>ダーティリード</p>
<ul>
<li>他transactionの、未コミットの内容が見える</li>
</ul>
</li>
<li>
<p>ファジーリード</p>
<ul>
<li>他transactionのcommit済みの更新・削除したデータが見える
<ul>
<li>読み取りを行うたびに結果が変わる可能性がある現象</li>
</ul>
</li>
</ul>
</li>
<li>
<p>ファントムリード</p>
<ul>
<li>他transactionのcommit済みの挿入されたデータが見える
<ul>
<li>読み取りを行うたびに結果が変わる可能性がある現象</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>このほかロストアップデートと言って、先行transactionの更新内容を後続のtransactionが上書きしてしまう挙動もあるらしい</p>
<h1 id="acid特性">ACID特性</h1>
<ul>
<li>Atomicity
<ul>
<li>タスクがall or nothingであること（すべて実行されるもしくはまったく実行されない）</li>
</ul>
</li>
<li>Consistency
<ul>
<li>整合性を満たす</li>
</ul>
</li>
<li>Isolation
<ul>
<li>操作の過程が他の操作から隠蔽される</li>
</ul>
</li>
<li>Durability
<ul>
<li>完了がユーザに通知されたタイミングで操作が永続的になり結果が失われないこと</li>
</ul>
</li>
</ul>
<h1 id="innodbのrepeatable-readのlock">InnoDBのREPEATABLE READのlock</h1>
<p>ハマりどころがあるようだ<br>
lockを獲得する読み取りが、ロストアップデートに対応するために、REPEATABLE READな挙動にならないらしい</p>
<p>どうやらlockしている行を参照しようとするとlock解除まで待ち、その後最新の値を取得するようだ<br>
これはREPEATABLE READが本来保障する挙動になっていない（値が変わってはいけないので）</p>
<p>この挙動、lock for updateでselectかけるにしか起きないらしい。ややこしいな<br>
locking readはread commited相当の挙動になると覚えるのがよい？</p>
<p>transaction開始直後にlocking readするなど、特定の状況では意識したほうが良いらしい（今の知識じゃ出来る気しないけど...）</p>
<h1 id="行ロック">行ロック</h1>
<p>indexの有無でlockの挙動が変わるとか聞いた</p>
<ul>
<li>レコードロック
<ul>
<li>インデックスレコードのロック</li>
</ul>
</li>
<li>ギャップロック
<ul>
<li>インデックスレコードの間のギャップのロック</li>
<li>もしくは、インデックスレコードの先頭の前、末尾の後のギャップのロック</li>
<li>indexの対象カラムに、50,51,100のレコードがそれぞれあるとき、100のレコードをfor updateでlockすると<br>
51と100の間にはinsertできない。51より前はできる。100以上はできない、となる</li>
<li>複合indexの場合はもうちょいややこしそう</li>
<li>primary key, unique keyの場合は、対象が一意に定まるので、そのレコードがあればそれだけlockする形になり、ギャップロックは発生しない</li>
</ul>
</li>
<li>ネクストキーロック
<ul>
<li>インデックスレコードに対するレコードロックと、その前にあるギャップに対するギャップロックの組み合わせ</li>
</ul>
</li>
</ul>
<h1 id="メモ">メモ</h1>
<ul>
<li>lock取得は、排他ロックはfor update、共有ロックはlock in share mode</li>
</ul>
<h1 id="参考文献">参考文献</h1>
<ul>
<li>https://github.com/ichirin2501/doc/blob/master/innodb.md#%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E5%88%86%E9%9B%A2%E3%83%AC%E3%83%99%E3%83%AB</li>
<li>https://techblog.kayac.com/repeatable_read.html</li>
<li>http://nippondanji.blogspot.com/2013/12/innodbrepeatable-readlocking-read.html</li>
</ul>

トランザクション分離レベルとロックについて勉強した

<h1 id="動機">動機</h1>
<p>joinやorderbyやら、概念はわかるけどちゃんと呼吸するように書くことはできない<br>
しかも普段ORMで雰囲気でやっているので、もっとSQLの特にqueryの書き方の知識を深めたかった</p>
<p>特にわかっていないキーワードを羅列しておく。読み終わった後、これについて説明できるようになっているとよい</p>
<ul>
<li>サブクエリ</li>
<li>join</li>
</ul>
<h1 id="メモ">メモ</h1>
<ul>
<li>
<p>selectでは存在しないcolumn名を指定できる</p>
<ul>
<li>select 100 from XXX とかやると、レコードの数だけに100の入った結果が得られる。f0_とか表示されてた</li>
</ul>
</li>
<li>
<p>selectでは、columnの値で演算できる</p>
<ul>
<li>select quantity, revenue, revenue / quantity のような指定もできる</li>
</ul>
</li>
<li>
<p>selectのasでつけた別名はorder byでは参照できるが、whereでは参照できない</p>
</li>
<li>
<p>booleanカラムにis not trueとかやるとnullも帰ってくるので注意</p>
</li>
<li>
<p>except(カラム名)でselectで取得しないという処理ができる</p>
</li>
<li>
<p>分析のためにはグループ化の概念が大事</p>
<ul>
<li>集めた基準ごとにデータの平均をとったり合計取ったりして他と比べることで分析を行う</li>
<li>group byにselectで指定した内容と同じものを投げるとまとめることができる</li>
<li>グループ化の対象にしないカラムをselectに指定してはいけない
<ul>
<li>selectで逆にグループ化対象のカラムを指定しない場合、結果には表示されないがqueryは実行できる</li>
</ul>
</li>
<li>金額や販売金額といった量的なデータは集計関数で集計しないといけない</li>
<li>group byに複数指定した場合は、取りうる組み合わせ分のrecordが帰る</li>
</ul>
</li>
<li>
<p>集計関数</p>
<ul>
<li>COUNT
<ul>
<li>個数を数える</li>
<li>COUNT(DISTINCT column名)とかもいける
<ul>
<li>重複を排除した個数を調べる</li>
</ul>
</li>
<li>nullはカウントしない</li>
</ul>
</li>
<li>SUM, AVG, MAX, MINは名前のまんま</li>
<li>標準偏差を求める、STDDEV_POPや募集号の一部から標準偏差を求めるSTDDEV_SAMPなんかもある
<ul>
<li>統計集計関数というんですって</li>
</ul>
</li>
</ul>
</li>
<li>
<p>集計結果の絞り込み、HAVING</p>
<ul>
<li>where句はorder byより先に来るので、order byでグループ化した後には使えない</li>
<li>この時にhavingで条件を指定して絞り込む</li>
<li>from > where > group by > having > select > order by > limitの順で実行される
<ul>
<li>limitは表示するレコードを決めているだけで、処理が速くなるとかはなさそうだ</li>
</ul>
</li>
</ul>
</li>
<li>
<p>より柔軟なグループ化</p>
<ul>
<li>CASEとIFを覚える</li>
<li>IF
<ul>
<li>IF (cond, true case, false case)</li>
<li>condにはorやandも使える</li>
</ul>
</li>
<li>IFをif elseのように複数使いたいときに使うのがCASE文</li>
<li>CASE WHEN cond THEN ... END
<ul>
<li>ELSEでいずれにも一致しなかった分岐</li>
<li>大小比較も、IN、BETWEENも使える</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>sqlの例。10回以上pageviewのあるユーザ絞り込み<br>
recordとpageviewsが1:1なのでこの場合はcountそのままでよい（重複を消すときはdistinctをつける）</p>
<pre><code class="hljs language-sql"><span class="hljs-keyword">select</span> user_id, <span class="hljs-built_in">count</span>(<span class="hljs-operator">*</span>) <span class="hljs-keyword">as</span> pageviews
<span class="hljs-keyword">from</span> sample.web_log
<span class="hljs-keyword">where</span> media <span class="hljs-operator">=</span> "email" 
<span class="hljs-keyword">and</span> user_id <span class="hljs-keyword">is</span> <span class="hljs-keyword">not</span> <span class="hljs-keyword">null</span>
<span class="hljs-keyword">group</span> <span class="hljs-keyword">by</span> user_id
<span class="hljs-keyword">having</span> pageviews <span class="hljs-operator">>=</span> <span class="hljs-number">10</span>
</code></pre>
<ul>
<li>
<p>テーブルの結合</p>
<ul>
<li>JOINはご存じテーブルをつないで横に伸ばすあれ</li>
<li>一方UNIONは縦につなぐらしい（使ったことない）</li>
</ul>
</li>
<li>
<p>join四種類</p>
<ul>
<li>INNER JOIN 内部結合
<ul>
<li>よく使うのがこれ</li>
<li>二つのテーブルが共通して持つカラムの値が重なっているレコードのみを残す</li>
</ul>
</li>
<li>LEFT OUTER JOIN 左外部結合
<ul>
<li>先に指定したテーブルを左側にする</li>
<li>右側は左側と値が重なってるレコードのみ表示</li>
</ul>
</li>
<li>RIGHT OUTER JOIN 右外部結合
<ul>
<li>先に指定したテーブルを左側にする</li>
<li>右側が全部。左側は重なってるレコードのみ</li>
</ul>
</li>
<li>FULL OUTER JOIN
<ul>
<li>二つのテーブルにある全レコードを残す</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>基本的な構文は以下のような感じ</p>
<pre><code class="hljs language-sql"><span class="hljs-keyword">select</span> <span class="hljs-operator">*</span> <span class="hljs-keyword">from</span> tbl_a <span class="hljs-keyword">inner</span> <span class="hljs-keyword">join</span> tbl_b <span class="hljs-keyword">on</span> tbl_a.id <span class="hljs-operator">=</span> tbl_b.id
</code></pre>
<p>onの代わりにusing(id)のような書き方もできる<br>
onのときは各テーブルのカラムが残るが、usingの場合カラムが一つにまとめられる</p>
<p>on の条件はandで複数指定することができる。ここをさぼるとレコードが増えたりするので、クエリの実行後の件数には気を配ったほうが良いらしい</p>
<ul>
<li>
<p>self join</p>
<ul>
<li>同一テーブルに年度ごとの売り上げがあるとき、前の年との売り上げの比較などをしたいときに使う</li>
<li>ただしself joinという構文はなく、inner join の対象がどっちも同じtableになる</li>
<li>onで算術演算子が使えるので tbl.year = tbl.year - 1 みたいに書ける</li>
<li>そのままだといっぱい出てくるので、where句で左側の条件を絞るとすっきりする</li>
</ul>
</li>
<li>
<p>IFNULL関数</p>
<ul>
<li>select句で使える。大量のカラムがnullだった時に別の値を入れることができる</li>
</ul>
</li>
<li>
<p>COALESCE関数</p>
<ul>
<li>置き換え対象を固定値ではなく、指定したカラムの値が設定される</li>
</ul>
</li>
<li>
<p>unionは結合ではなく集合演算</p>
<ul>
<li>集合同士の足し算</li>
<li>集合演算なので差分をとるEXCEPT、重複をとるINTERSECTもある</li>
<li>同じスキーマのテーブルで使うが、ビッグデータでは月ごとにテーブルを切ることがある</li>
<li>そういう時に先月も今月もあったレコード、とか先月は売れたが今月は売れてないレコードといったものを探す</li>
<li>構文
<ul>
<li>selct * from tbl1 union distinct(もしくはunion all) select * from tbl2</li>
<li>distinctかallかは、双方に重複がないときは結果が変わらない
<ul>
<li>ちなみに重複はselectのパラメタの内容すべてに対してである。selectに指定しなかった内容は考慮されない</li>
</ul>
</li>
<li>field名は一致が必要</li>
</ul>
</li>
</ul>
</li>
<li>
<p>仮想テーブル</p>
<ul>
<li>なにがしかのSQLの結果をテーブルとして扱い、それに対してクエリを投げることができる</li>
<li>with 仮想テーブル名 as (仮想テーブルを作るSQL)で仮想テーブルを作成できる</li>
<li>withの後ろの仮想テーブル名 as (SQL) の組み合わせは複数作れる</li>
</ul>
</li>
<li>
<p>cross join</p>
<ul>
<li>テーブルのレコードの組み合わせすべて分のレコードを生成するjoin</li>
<li>平均値のみを出力するSQLをwithにたたいて、それをcross joinすると対象のテーブルのレコードに平均値カラムを追加した結果が得られる</li>
</ul>
</li>
</ul>
<pre><code class="hljs language-sql"><span class="hljs-keyword">select</span> product_id <span class="hljs-keyword">from</span> qty_jul_sep
<span class="hljs-keyword">except</span> <span class="hljs-keyword">distinct</span>
<span class="hljs-keyword">select</span> product_id <span class="hljs-keyword">from</span> qty_oct_dec
</code></pre>
<p>これで差集合演算, distinctをつけると重複が消える</p>
<ul>
<li>
<p>サブクエリ</p>
</li>
<li>
<p>仮想テーブルを使うWITH以外の方法</p>
<ul>
<li>WHERE句でもHAVING句でも、SELECTの対象指定でも使える</li>
<li>WHERE inの対象にしたり、集計関数で値にしてから比較演算に使ったり</li>
</ul>
</li>
<li>
<p>縦持ちと横持ち</p>
<ul>
<li>この変換はサブクエリの用途として多いらしい</li>
<li>縦持ちテーブルはよくあるrecord
<ul>
<li>東京、H29, 986円</li>
<li>東京、H30, 1094円</li>
<li>みたいな感じ</li>
<li>年が増えるとレコードが増える</li>
<li>一般的なのはこっち</li>
</ul>
</li>
<li>横持ちテーブルは、縦持ちで重複のあるカラムをまとめて集計したもの
<ul>
<li>東京, 958(H29の最低賃金), 985(H30の最低賃金),998(H31の最低賃金)</li>
<li>みたいな感じ</li>
<li>年が増えるとカラムが増える</li>
</ul>
</li>
<li>横持ちテーブルへのselectとunionを使うと縦持ちにできる</li>
<li>table構造を変えることで、集計などが行いやすくなる</li>
</ul>
</li>
<li>
<p>メモ</p>
<ul>
<li>レコード一つの仮想テーブルでも、計算とかで扱いたいときはmaxを通す必要がある（minでもいけそう）。要するにscalaにしないとだめ</li>
<li>[val]かvalかってこっちゃな</li>
<li>having句でも算術演算はできるし、集計関数も使える</li>
<li>group byでグループ化するとき、対象のカラムは集計関数に投げる必要がある
<ul>
<li>record一つの場合は、maxやavgを通す必要がある(1つを集計する)</li>
<li>複数レコードの同一の値をまとめるという意味もある</li>
</ul>
</li>
</ul>
</li>
</ul>

集中演習SQL入門 BigQueryではじめるビジネスデータ分析を読んだ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E8%AA%AD%E3%82%80%E5%89%8D%E3%81%AE%E9%9B%91%E6%84%9F">読む前の雑感</a></li>
<li><a href="#%E5%8D%98%E8%AA%9E%E3%83%A1%E3%83%A2">単語メモ</a></li>
</ul>
<h1 id="読む前の雑感">読む前の雑感</h1>
<p>暗号技術とテスト駆動開発についての特集があってよさそう</p>
<h1 id="単語メモ">単語メモ</h1>
<ul>
<li>
<p>乱数の重要な性質</p>
<ul>
<li>再現不可能性、予測不可能性、無作為性（統計的な偏りがない）</li>
</ul>
</li>
<li>
<p>MAC</p>
<ul>
<li>Message Authentication Code</li>
<li>MacアドレスはMediaAccessControll</li>
</ul>
</li>
<li>
<p>拡張ユークリッドの互除法</p>
<ul>
<li>ユークリッドの互除法とは二つの整数の最大公約数を求めることができる方法</li>
<li>GCD(a,b)は、大きいほうを小さいほうで割ったあまりと、小さいほうで再帰的に呼び出し、割り切れたものを最大公約数とするやり方
<ul>
<li>長方形を正方形で順番に区切っていくイメージ</li>
<li>ax+by = gcd(a,b)の解となる整数x,yの組が計算できる。この応用を拡張ユークリッド互除法と呼ぶ</li>
</ul>
</li>
<li>RSA暗号では鍵生成時に秘密鍵の値を求めるのにこの拡張ユークリッド互除法を使う</li>
</ul>
</li>
<li>
<p>生体情報、所持情報、知識情報</p>
</li>
<li>
<p>現象計算困難性</p>
<ul>
<li>あるメッセージダイジェストと同じメッセージダイジェストとなるメッセージを見つけるのが困難という性質</li>
</ul>
</li>
<li>
<p>テストにコストがかかることの解決方法はテストをうまくなることであって削ることではない</p>
<ul>
<li>ええ言葉や</li>
</ul>
</li>
</ul>

SoftwareDesign 3月号メモ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#react%E3%81%AEtips">Reactのtips</a>
<ul>
<li><a href="#usestate%E3%81%AE%E9%81%85%E5%BB%B6%E8%A9%95%E4%BE%A1">useStateの遅延評価</a></li>
<li><a href="#component%E3%82%92%E8%BF%94%E3%81%99hooks%E3%81%AE%E6%98%AF%E9%9D%9E">componentを返すhooksの是非</a></li>
</ul>
</li>
</ul>
<h1 id="reactのtips">Reactのtips</h1>
<p>最近覚えた細かいtipsをメモしておく</p>
<h2 id="usestateの遅延評価">useStateの遅延評価</h2>
<pre><code class="hljs language-js"><span class="hljs-keyword">const</span> [count, useCount] = useState&#x3C;number>(<span class="hljs-number">0</span>)
</code></pre>
<p>このようなコードがあるとき、useStateの引数はcountの初期値である<br>
この初期値には値を返す関数を指定できる</p>
<pre><code class="hljs language-js"><span class="hljs-keyword">const</span> [count, useCount] = useState&#x3C;number>(<span class="hljs-function">() =></span> <span class="hljs-number">0</span>)
</code></pre>
<p>一見なんのこっちゃわからないけれど、この関数は初回renderのcountの初期化でのみ使われる<br>
この関数がuseStateの外にあるとrenderされるたびに呼ばれるが、useStateに渡せば1度で良いというのがポイント</p>
<h2 id="componentを返すhooksの是非">componentを返すhooksの是非</h2>
<p><a href="https://engineering.linecorp.com/ja/blog/line-securities-frontend-3/">この記事にあるように</a><br>
hooksからcomponentとその状態を表すstateを返すパターンがある</p>
<p>これによってそのcomponentが表す状態を親componentからhooksに押し込めることができる<br>
今まで親がこれらのロジックを定義していたが、子componentが複数あると親componentが散らかっていたので、<br>
それをhooksに分離することで見通しが良くなりそうだ。</p>
<p>ただし依存の向きが逆転している気もするので、ある程度Reactがわかっていないとごっちゃごちゃなコードが生えそうな予感もするし<br>
複数のcomponentが協調しないといけない場合、それをどこが持つのかという判断が難しそう</p>
<p>複数のcomponentが協調して一つのロジックを作るのであれば、複数のcomponentを返すhooksになればよいのかな...?</p>

Reactのtips

詳解Rustプログラミングを読んだ

Zero To Production In Rustをやった

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#rust%E3%81%A7%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%A8%E3%83%87%E3%82%A3%E3%82%BF%E3%83%BC%E3%82%92%E4%BD%9C%E3%82%8B%E8%A8%98%E4%BA%8B%E3%82%92%E3%82%84%E3%81%A3%E3%81%9F">Rustでテキストエディターを作る記事をやった</a></li>
<li><a href="#%E6%84%9F%E6%83%B3">感想</a></li>
<li><a href="#raw-%E3%83%A2%E3%83%BC%E3%83%89-canonical-%E3%83%A2%E3%83%BC%E3%83%89">Raw モード, Canonical モード</a></li>
<li><a href="#%E4%BD%BF%E3%81%A3%E3%81%9Fcrate">使ったcrate</a>
<ul>
<li><a href="#1%E7%AB%A0">1章</a></li>
<li><a href="#2%E7%AB%A0">2章</a></li>
<li><a href="#3%E7%AB%A0">3章</a></li>
<li><a href="#4%E7%AB%A0">4章</a></li>
<li><a href="#5%E7%AB%A0">5章</a></li>
<li><a href="#6%E7%AB%A0">6章</a></li>
<li><a href="#7%E7%AB%A0">7章</a></li>
</ul>
</li>
</ul>
<h1 id="rustでテキストエディターを作る記事をやった">Rustでテキストエディターを作る記事をやった</h1>
<p><a href="https://www.philippflenker.com/hecto/">記事はこれ</a></p>
<p>単純な興味と、基礎的な部分が学べそうなところとvimの理解に通ずる点がありそうだったのでやってみた</p>
<h1 id="感想">感想</h1>
<ul>
<li>terminalにも色やカーソル移動を指示するエスケープシーケンスが存在することを知れた
<ul>
<li>色付けもこれで行う。特定の色にセットするエスケープシーケンスと合わせて文字をprint!するイメージ</li>
</ul>
</li>
<li>改行だったり、行末でdeleteしたときの挙動など、普段気にせず使っている挙動の実装について知れた</li>
<li>めちゃくちゃ高度なことをするというよりは、ひたすら場合分けして実装という感じだった
<ul>
<li>もっと難しいアルゴリズムとかでてくるのかと思ったけど意外と質素</li>
</ul>
</li>
</ul>
<h1 id="raw-モード-canonical-モード">Raw モード, Canonical モード</h1>
<ul>
<li>terminalにはモードの概念がある
<ul>
<li>デフォルトはcanonicalで始まる。これはcookedモードとも呼ばれる</li>
</ul>
</li>
<li>canonicalモードではエンターが押下されるまで入力を受け付ける</li>
<li>逆にrawモードにすることで入力を即時で受け取る
<ul>
<li>厳密には非canonicalモードがあり、入力されたキーが画面に表示されず、<br>
C-cのような強制終了が効かなくなるんだとか</li>
</ul>
</li>
</ul>
<h1 id="使ったcrate">使ったcrate</h1>
<ul>
<li>termion
<ul>
<li>terminalに関する操作をあれこれ提供してくれるクレート</li>
<li>標準入出力の代わりに使う</li>
<li>terminalは自分のstateを持っていて、そこでやり取りする</li>
</ul>
</li>
<li>unicode-segmentation
<ul>
<li>書記素クラスタを正しく扱うために必要。これがないとカーソルが移動するとき、マルチバイト文字で正しく移動できない
<ul>
<li>Stringはu8[]のラッパのようなものだが、文字は2byteのものがあったりするので、単純にchars()で一つ次に移動溶かしても思ったとおりに動いてはくれない</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="1章">1章</h2>
<p>環境構築なので割愛</p>
<h2 id="2章">2章</h2>
<ul>
<li>byteコードとcharに変換した結果を眺める
<ul>
<li>Enterがバイトコードだと13とかそういうの</li>
<li>C-[のバイトコードがEscと同じで、だからvimだとこれでinsert抜けれるというのはどこかで読んだことがあったんだけど、実際にどちらも27で一致していた</li>
<li>Ctrl+a-zが1-26にマップされている</li>
</ul>
</li>
<li>is_control関数
<ul>
<li>プリントできない文字がcontrol character</li>
<li>とりあえずASCII以外って理解でよさそう</li>
</ul>
</li>
</ul>
<h2 id="3章">3章</h2>
<p>Raw input/outputを扱う</p>
<ul>
<li>
<p>idiomatic codeとは慣用的な表現をちゃんと使おうって事</p>
<ul>
<li>clippyに従おう！</li>
</ul>
</li>
<li>
<p>structとかnewの説明がなされてる。この辺りは初心者向き</p>
</li>
<li>
<p>escapeシークエンスをprint!("\x1b[2J")のようにしてておもろい</p>
<ul>
<li>termionにはこれらのシーケンスがわかりやすく定義されてる</li>
<li>termion::clear::Allとか</li>
</ul>
</li>
<li>
<p>termion回りが一番おもろかったな</p>
</li>
<li>
<p>editorでカーソル移動するところまで作った</p>
</li>
</ul>
<h2 id="4章">4章</h2>
<ul>
<li>ファイルの読み込みからの表示を実装した</li>
<li>カーソルで読み込んだファイルの中を自由に移動するためにoffsetを導入する
<ul>
<li>offsetは、可視の範囲にカーソルが入っているかどうかを判定するのにも使う</li>
</ul>
</li>
<li>マルチバイト文字対応
<ul>
<li>unicode-segmentationなるクレートを使う</li>
<li>Grapheme(書記素)
<ul>
<li>文字として区別できる最小単位</li>
</ul>
</li>
</ul>
</li>
<li>色付けはTermionの関数経由で行う。これもどうやらエスケープシーケンスがあるようだ</li>
<li>statusbarの表示までやるので見た目がそれっぽくなってきて楽しい</li>
</ul>
<h2 id="5章">5章</h2>
<p>ここからようやくファイルを編集できるようにする</p>
<ul>
<li>deleteやbackspace、文字の入力に対応して楽しい</li>
<li>削除や追加、enterは地味に考えることが多い
<ul>
<li>行の途中でenter押したら改行するので、Rowの情報を前後に分けるとか</li>
<li>行の右端でdelete押したら下の行が上がってくるとか</li>
<li>普段何気なく使っている挙動について再認識できて面白い</li>
</ul>
</li>
<li>保存時の処理も作る</li>
</ul>
<h2 id="6章">6章</h2>
<p>検索を作る</p>
<ul>
<li>シンプルな検索は、線形探索
<ul>
<li>graphemeで文字のindexを正しく受け取らないといけない</li>
</ul>
</li>
<li>インクリメンタルサーチも作る
<ul>
<li>Promptでclosureを受けるようにして、loop後にcallbackを呼ぶようだ</li>
<li>検索結果の移動は、現在より後ろに検索範囲を限定して再度検索を呼ぶという形になっている
<ul>
<li>一覧を保持しているのかと思ったけど確かにこれでも動くなー</li>
</ul>
</li>
</ul>
</li>
<li>検索方向を変えるのは結構大変</li>
</ul>
<h2 id="7章">7章</h2>
<p>シンタックスハイライトを作る<br>
あまり乗り気になれなかった...</p>
<ul>
<li>lexerのような構造体はでてこない
<ul>
<li>行のstringを保持するRow構造体がhighlightの処理も行う</li>
<li>rustの構文に色付けしていく</li>
</ul>
</li>
</ul>

Rustでテキストエディターを作る記事をやった

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#css%E3%81%A8utility-first">CSSとutility first</a>
<ul>
<li><a href="#%E4%BB%8A%E3%81%BE%E3%81%A7%E3%81%AEcss%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%A8%E8%A7%A3%E6%B1%BA%E3%81%97%E3%81%9F%E3%81%8B%E3%81%A3%E3%81%9F%E8%AA%B2%E9%A1%8C">今までのCSSに関するアーキテクチャと解決したかった課題</a></li>
<li><a href="#tailwindcss%E3%81%AE%E6%A6%82%E8%A6%81%E3%81%A8%E8%A7%A3%E6%B1%BA%E6%96%B9%E9%87%9D">tailwindcssの概要と解決方針</a>
<ul>
<li><a href="#css%E3%81%AE%E5%9B%9B%E5%A4%A7%E5%8E%9F%E5%89%87">CSSの四大原則?</a></li>
</ul>
</li>
<li><a href="#atomic-css-in-js">Atomic CSS in JS?</a></li>
<li><a href="#%E3%81%BE%E3%81%A8%E3%82%81">まとめ</a></li>
</ul>
</li>
</ul>
<h1 id="cssとutility-first">CSSとutility first</h1>
<p>最近<a href="https://tailwindcss.jp/">tailwindcss</a>のような、utility firstを標榜するライブラリが、フロントエンド界隈で見られる<br>
合わせてAtomicなCSS in JSといった単語も見かける</p>
<p>フロントエンドを触る以上ある程度の知識が必要だろうということで、この機会に気になる単語の概要を洗ってみる</p>
<p>(ちなみに自分自身はstyleをcssフレームワークに任せてばかりなので、そこまでCSSに知見と経験があるわけではない)</p>
<h2 id="今までのcssに関するアーキテクチャと解決したかった課題">今までのCSSに関するアーキテクチャと解決したかった課題</h2>
<p>自分の理解ではcssはglobalな設定であり、影響範囲の見通しの悪さ(==保守性の低さ)が問題であり、<br>
それを解決するためにBEMのような設計原則みたいなものが生まれてきた(と理解している)</p>
<p>見通しの悪さという点で、 <strong>Vue</strong> や <strong>React</strong> などのライブラリではcomponentに閉じたstyleを適用できるようにしてある程度解決している印象がある</p>
<h2 id="tailwindcssの概要と解決方針">tailwindcssの概要と解決方針</h2>
<p>新しいライブラリを覚える時はそのライブラリが解決したい課題を掘り下げると良い（と思っている）<br>
<a href="https://tailwindcss.jp/docs/utility-first">documentによると</a></p>
<blockquote>
<p>制約された単純なユーティリティのセットから複雑なコンポーネントを構築します</p>
</blockquote>
<p>とある。これはunixのコマンドのように、小さな範囲に関心のあるものを組み合わせて、<br>
複雑なUIを作ろう、という考え方に聞こえる</p>
<p>解決する課題はCSS保守性の低さであると感じた。<br>
見た目はこんな感じになるようだ</p>
<pre><code class="hljs language-html"><span class="hljs-tag">&#x3C;<span class="hljs-name">div</span> <span class="hljs-attr">class</span>=<span class="hljs-string">"max-w-sm mx-auto flex"</span>></span>...<span class="hljs-tag">&#x3C;/<span class="hljs-name">div</span>></span>
</code></pre>
<p>classNameそれぞれに対応したstyleが定義されていて、それを組み合わせてstylingしていくようだ</p>
<p>メリットとして</p>
<ul>
<li>クラス名を考える必要がない</li>
<li>cssが肥大化しない</li>
<li>htmlのクラスはlocalなので、変更を加えるのが怖くない</li>
</ul>
<p>といったものがあるようだ。inlineでstyleを書いたり、cssのpropsとの差はなにかという気持ちになったがこれにもdocumentに記載がある<br>
擬似クラスなどが使用できる点や、設定を元にstyleを決定できるところが良いみたいだ<br>
メディアクエリの必要なレスポンシブにも対応している</p>
<p>特にcssが肥大化しないというのは大きいように感じる。componentに閉じたstyleであっても、<br>
同じような表現を形の違う別のcomponentで使いたい時はそれぞれに定義する必要があるだろう（例えば色やpaddingとか）。これを使いまわそうとするとcomponentに閉じていたstyleが漏れてしまって意味がない</p>
<h3 id="cssの四大原則">CSSの四大原則?</h3>
<p><a href="https://philipwalton.com/articles/css-architecture/">CSS Architecture</a>という記事に、CSSは</p>
<ul>
<li>予測可能である(predictable)</li>
<li>再利用可能である（reusable）</li>
<li>メンテナンス可能である（mantainable）</li>
<li>スケール可能である(scalable)</li>
</ul>
<p>とある。これを踏まえるとtailwindcssはこれらの項目をある程度満たしているように感じた</p>
<p>classNameでの宣言は予測可能であるし、細かい粒度で作られたstyleは再利用可能である<br>
メンテナンス可能性についてはうまくいえないが、スケーラブルであるのは間違いないだろう<br>
必要なデザインが増えたとしても、既存のクラスの組み合わせで実現可能だからだ</p>
<h2 id="atomic-css-in-js">Atomic CSS in JS?</h2>
<p><a href="https://sebastienlorber.com/atomic-css-in-js">Atomic CSS-in-JS</a></p>
<p>最近タイムラインで見かけた記事で、おもしろそうだったので軽く目を通してみた<br>
冒頭に書かれているが、Component分割の考え方であるAtomicDesignとは関係がない概念である</p>
<p>概念と書いた通り、Atomic CSS in JSは特定のライブラリなどを指すものではなく考え方であるようだ</p>
<p>内容的には極端にしたutility firstなcssで、一つのclassに一つのstyleを当てる</p>
<p>(以下は上記のリンクより転載)</p>
<pre><code class="hljs language-css"><span class="hljs-selector-class">.bw-2x</span> {
  <span class="hljs-attribute">border-width</span>: <span class="hljs-number">2px</span>;
}
<span class="hljs-selector-class">.sans</span> {
  <span class="hljs-attribute">font-style</span>: sans-serif;
}
</code></pre>
<p>共通のスタイルだろうとその場限りのスタイルだろうと同じように扱えたり、<br>
必要なCSSをすべて抽出することが可能だそうだ</p>
<p>参考になるものとして、TwitterのReact-Native-WebとFacebookのStylexが上げられていたが、深くは追いかけていない</p>
<p>今後流行ってくるかもなーぐらいの気持ちでwatchしようと思う</p>
<h2 id="まとめ">まとめ</h2>
<p>CSSのutility firstなる概念について、tailwindcssからある程度知見を得た<br>
CSSの保守は複雑であり、それを解決する方向性としてでてきたものがutility firstである<br>
小さいものを組み合わせて複雑なものを作るという考え方は非常に共感できた</p>
<p>実際は保守性だけではなく、不要なcssを生成しないか、のようなパフォーマンスに関わる観点も重要だろう。CSS Moduleは補完なども効かせづらい代わりにこの辺の最適化がやりやすいらしい</p>
<p>今後何が流行るかはわからないが、近年のwebアプリの複雑さは増して来ていて、それに追従するために技術も進歩しているのを感じられて良かった</p>
<p>有名だがtailwindcssの思想を持ち込んだCSS in JSライブラリに<a href="https://chakra-ui.com/">ChakraUI</a>がある。型補完などの恩恵も受けられて嬉しい。今度新しく何かを作る時は使ってみたい</p>

CSSのUtility firstという概念について学んだ

<h1 id="toc">ToC</h1>
<ul>
<li><a href="#%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AE%E7%9B%AE%E7%9A%84">ブログの目的</a></li>
</ul>
<h1 id="ブログの目的">ブログの目的</h1>
<p>この投稿がこのメモブログの最初の投稿です</p>
<p>主に以下の目的で作成しています</p>
<ul>
<li>普段のメモをmdで取るのでそれをそのまま備忘録にしたい</li>
<li>next.jsの学習</li>
<li>cssの学習</li>
</ul>