モダンなWeb界隈調査【SSG・JAMStack】

あらすじ

前回この記事を書きました。ただ懸念点が一つ・・・2010年。古すぎじゃい!
やっぱり本で勉強するよりネットサーフィンの方がええわ!
分からない単語が出てきたら深堀って調べていこうと思います。
melheaven.hatenadiary.jp

2021年現在モダンとされている技術は何かを調べてみました。
この方が超分かりやすくまとめてくださっていたので、この技術を軸に挑戦できれば自作ブログでも夏季休暇中に作ろうと思います。
coliss.com

フレームワーク

「Vue vs React」の二強。半年前にVueでポートフォーリオを開発したっきり触れていません。でもこの構図は半年前から変わってはいませんね。

静的サイトジェネレーター(SSG)

知らん・・・・。下の記事がヒット。
fastcoding.jp

WordpressではCMSが採用されています。Webサイトのコンテンツ情報をDBにて一元管理します。DBから情報を取得して、サーバーが情報を含んだHTMLを生成することが一般的です。

SSGではビルド時に全てのHTMLを書き出してしまい、生成されたファイルをホスティングサービスで公開する方法です。
ちなみにNetlifyではサーバー管理を考えなくとも、トリガー後にただただコードを実行してくれるサーバーレスで公開するには相性が良いです。

DB・管理画面が必要としないのなら、セキュリティ的にはリスクは低いでしょうし、サイトの高速化につながるのでSEOには良いかも!

JAMstack(JavaScript/APIs/Markup)

知らん・・・・。下の記事がヒット。
qiita.com

上記の記事ではSPA(Single Page Application)とサーバーレスとの比較がなされていました。おさらいですが、SPAでは単一のページでコンテンツの切り替えを行うことでページ遷移しなくてもいいやん!速い!を実現できるシステムです。

JAMstackではサーバー側から静的HTMLの配信だけを行うようです。

でもそれじゃあ静的ページでしか扱えないんとちゃうの?と思ったのですが・・・(SSGっぽいよな)

monotein.com

ビルドのタイミングでAPIからデータを取得して、HTMLを生成します。

でもそれじゃあデータの更新が反映されないのでは・・・(ビルドってデプロイの時しかしないやろ)

データ更新時にビルド・デプロイを行なって最新状態を保つそうです。

例えば私がブログ記事を投稿した瞬間、サーバーレスのトリガー機能が発火し、ビルド・デプロイを行い、
最新コンテンツをAPIで取得したHTMLを生成してくれるわけです。

ビルド・デプロイを何度も行うって凄い大変そうに聞こえるのですが・・・(なんか重そう/ 小並感)

CI/CDでテスト・ビルド・デプロイが自動化が当たり前なので大丈夫!
qiita.com

感想

上記の記事はコンテンツが文字ベースのブログ投稿サービスにはうってつけ、静的サイトジェネレータとしてVueベースならNuxt、ReactベースならGatsbyなどが使えそうです。ホスティングサービスも静的HTMLを配信できるNetlifyなどが相性良さげですね。

自作ブログを製作したいので、これらの技術をもう少し調べていこうと思います。

「Webを支える技術」(2010)を読んで【URI・HTTP】

はじめに

Web系の勉強をしてますが、もう少しWeb技術への基礎理解が欲しいので以下の本を読みました。
新しい技術が誕生するにせよ、RESTのような根幹の技術は変わりません。むしろWebの世界で統一化された規約(REST)を押させておこうと思いました。
ysk-pro.hatenablog.com

Webを支える技術をざっと読んだ内容

  • Web技術に関する背景
  • URI(リソース識別子)
  • HTTP(Protocol)
  • HTML(Hyper Media Format)
  • WebAPIの設計

知識の穴を今回はまとめていきます。

REST

REST(REpresentational State Transfer)とはWebにおける設計思想であるArchitecture Styleです。RESTなサービスとは「サービスのURIに対してHTTPメソッドでアクセスする事で情報(リソース)をHTML形式で取得する」考えが根底にあります。Webとは無数のWebサービスが存在しており、個別のWebサービスが全体を構築しています。個別のwebサービスが好き勝手に全体の調和を乱さないよう、あらかじめREST(規律・約束)を設けて、全体として統一させています。

qiita.com

REST = ULCODC$SS

クライアント/サーバ

最も有名なアーキテクチャスタイル。ユーザーインターフェースを担当するクライアントがサーバにリクエストを送り、サーバがデータストレージからデータを取得し、レスポンスを返します。

ステートレスサーバ

サーバがクライアントのセッション状態を保持していない事です。サーバ側の実装が簡略化され計算コストの省力化が利点。

  • キャッシュ(一度取得したリソースをクライアント側が保持)
  • 統一インターフェース(情報操作を全てHTTPメソッド(GET, POSTとか...)として統一する)
  • コードオンデマンド(サーバからプログラムをクライアント(JavaScriptが多め)にダウンロード)
  • 階層型(システムの階層化(負荷分散やプロキシの配置が該当))
  • 接続性(Web上のリソースを固有のURIで辿れる)

URI

URIは先ほどのWeb上に存在するリソースを識別するIDです。以下のような構成となっています。

URIスキーム・ユーザ情報・ホスト名・ポート番号:8000・パス・クエリ(q=test&debug=true(検索ワードとか))・URIフラグメント:#n10(HTMLのID属性の指定)

90年代後半頃はリンク切れが問題になっていたらしく、長く保てるURIについて議論されていたみたいです。現在だと当たり前の話ですが、URIにセッションIDやプログラミング言語に依存したワードを使用しない事が重要とされています。

詳細については以下の記事にてまとめてくれています。
reboot00.com

HTTP

HTTPのステートレス性

ステートレス性ではサーバがクライアントのアプリケーション状態を保存しておらず、リクエスト時にクライアントが全ての情報を送信しなければならない為、ステートフルと比べて簡潔性・冗長性によるデータ量の増加、負荷に欠点があります。

ログイン〜ログアウトの間の状態をセッション状態と呼びますが、これはステートフルが前提となっています。セッション状態では各サーバがクライアントの状態を管理しておく必要があります。クライアント数が増加した際に、各サーバには同時に相手にできるクライアント数には限界があります。サーバ台数が徐々に増加していき、スケールアウトしにくいシステム構成となります。

ステートレス性ではクライアントが自らのセッション状態を覚える為、サーバが各クライアントのセッション状態を覚える必要がなく、リクエスト処理に集中できます。

HTTPヘッダ

サーバやクライアントはメッセージのヘッダ部分を見てメッセージに対する挙動を決定します。
HTTPヘッダにはいくつか種類があります。

  • MIMEメディアタイプ(リソースの表現の種類 / text , image, video ...)
  • コンテントネゴシエーション(クライアント側が処理できる表現をサーバ側が考慮)

あとはチャンク・認証方式・キャッシュ・KeepAlive(リクエスト毎にTCP接続を切断しなくて済む)などです。

HTML

XMLとHTMLは異なります。XMLは<>で囲まれたタグに修飾情報を与えることによって、データの意味が分かりやすく、可読性が向上します。タグの要素名とデータの管理はXML文書内で記述します。
hnavi.co.jp

JSON

プログラミング言語から扱いやすいデータ構造であるため、JavaScriptで実行できること+冗長性が低いことからAjax通信におけるデータフォーマットとして活用されています。

JSONPによるクロスドメイン通信

Ajaxで用いるXMLHttpRequestでは不特定多数のサーバへのアクセス(=クロスドメイン通信)がセキュリティ上制限されています。代替手段としてJSONPを活用することでクロスドメイン通信を可能にしています。

感想

本を一から読むよりもまとめた記事をざっと眺める方が効率良いかもね。
ysk-pro.hatenablog.com

Scikit-Learnによる分類問題

あらすじ

お久しぶりです。最近ちゃっかり短編小説にハマっています。
研究室の後輩への引き継ぎ文書をtxtファイルからipynbファイルに移行しようと思い、このような活動を勝手に続けています。
ipynbファイルに移行することでプログラムを実行しながら、文書を読むという理解が深まりますから、非常に効率が良いですね。
一応ipynbファイルはGoogle Colab上で動作することを前提としています。

前回はScikit-Learnを用いた回帰問題についてまとめました。今回は分類問題をまとめました。
melheaven.hatenadiary.jp

資料

github.com

目次

目次は以下の通りです。ワインデータセットを適用して、n個の特徴量からワインを識別するという問題を与えました。以下の手法の中でそれぞれどの程度、精度を得られるのか、又は使用方法を簡単なモデルを組んで実装します。途中に各アルゴリズムの長所・短所や特徴を記載していますが、数式は長くなるので省きました。

次回

基礎編はこのくらいにして次回からは画像分類を上記で挙げたアルゴリズムからの派生形で適用してみます。
もしかしたら次元削減やクラスタリングについてもまとめるかも。

Scikit-Learnによる回帰問題

はじめに

最近研究室に後輩が増えてきました。自分の研究室は専門外のAIを扱うので、入ってくる学生はAIについては初心者ばかり。よって少しでも勉強資料を作成・更新して、自分の備忘録と学生の勉強に活かしてくれたらと思います。

作成した資料

できれば毎日更新していきたいです。
github.com

目次

  1. 「回帰問題どうすれば解けるんや」
  2. 単回帰モデル →「特徴量が複数個でも分析できるようにしてくれや」
  3. 重回帰モデル → 「特徴量が高次でも分析できるようにしてくれや」
  4. 多項式変換  → 「ファ?過学習しとるやんけ」
  5. 正則化    → 「次はパラメータベクトルが非線形でも解けるようにしてくれや」
  6. 確率的勾配降下法 → 「ひとまずここまでじゃ」

次回は回帰・分類ともに適用できるサポートベクトルマシンやランダムフォレストを紹介したいと思います。