fluid_27’s blog

勉強した内容をアウトプットするためのブログ

swaggerってなんぞ?

業務でswaggerとやらを使うことになるので軽く調べてまとめました。
自分の為の備忘録です。

swaggerとは・・・

OpenAPIを用いてREST APIを設計する際に使用するツールセットのこと。
https://qiita.com/teinen_qiita/items/e440ca7b1b52ec918f1b

OpenAPIとは

OpenAPIとは、RESTful APIを記述するためのフォーマットのこと。
Swagger 2.0を拡張して実装されている。
https://qiita.com/teinen_qiita/items/e440ca7b1b52ec918f1b

RESTful APIとは・・・

RESTの原則に則って構築されたWebシステムのHTTPでの呼び出しインターフェースのこと。
https://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2
2 つのコンピュータシステムがインターネットを介して安全に情報を交換するために使用するインターフェイスです。
https://aws.amazon.com/jp/what-is/restful-api/

RESTとは・・・

REST(REpresentational State Transfer)はWebサービスの設計モデルです。
RESTなWebサービスは、そのサービスのURIにHTTPメソッドでアクセスすることでデータの送受信を行います。
https://qiita.com/TakahiRoyte/items/949f4e88caecb02119aa

物語思考の感想

物語思考(著:けんすう)の感想

買って読む本ではないと感じた。
読む価値がないというわけではなく、twitterで著者のけんすうさんが言っていたようなことが改めて書いてあるような内容に感じたので。

言葉の選び方が丁寧で、読みやすく親しみやすい印象。
自分のやりたいことが見つからなくてあーだこーだしている人の背中を優しく押してあげるような本だったと思う。
ただ、目新しい価値観が提示されているでもなく、割と世に出回っている自己啓発本やハウツー本などで書かれているような内容が多かったような印象だった。
例)・なりたい自分を想像し、なりきる。演じる
  ・コンフォートゾーンを抜け出す
  ・自分がめちゃくちゃ努力する前に環境を選ぶ

けんすうさんのことはtwitterでずっとフォローしていて、個人的には好きなのでこれからもtwitterの投稿は見ると思う。

Laravel JetStream、Laravel Sunctom

Laravel JetStreamとは

Laravel JetStreamは、Laravelのためのに美しくデザインされたアプリケーションのスカフォールドです。ログイン、ユーザー登録、メール確認、2要素認証、セッション管理、Laravel Sanctumを使ったAPI、オプションとしてチーム管理を含んだ、次のLaravelアプリケーションの完璧なスタートポイントを提供します。

JetstreamはTailwind CSSを使用しデザインしており、LivewireかInertiaの使用を選択していただけます。
https://readouble.com/jetstream/1.0/ja/introduction.html

※スカフォールド・・・

アプリケーションに必要となる基本的操作(CRUD)を実現するためのファイルを自動生成する機能

Laravel Sunctomとは

SPA(シングルページアプリケーション)、モバイルアプリケーション、およびシンプルなトークンベースのAPIに軽い認証システムを提供します。Sanctumを使用すればアプリケーションの各ユーザーは、自分のアカウントに対して複数のAPIトークンを生成できます。

1つ目にSanctumは、OAuthの複雑さなしに、ユーザーにAPIトークンを発行するために使用できるシンプルなパッケージです。
ユーザーAPIトークンを単一のデータベーステーブルに保存し、有効なAPIトークンを含む必要があるAuthorizationヘッダを介して受信HTTPリクエストを認証することでこの機能を提供します。

2つ目にSanctumは、Laravelを利用したAPIと通信する必要があるシングルページアプリケーション(SPA)を認証する簡単な方法を提供するために存在します。
この機能のために、Sanctumはいかなる種類のトークンも使用しません。代わりに、SanctumはLaravelの組み込みのクッキーベースのセッション認証サービスを使用します。通常、SanctumはLaravelの「web」認証ガードを利用してこれを実現します。これにより、CSRF保護、セッション認証の利点が提供できるだけでなく、XSSを介した認証資格情報の漏洩を保護します。
Sanctumは、受信リクエストが自身のSPAフロントエンドから発信された場合にのみクッキーを使用して認証を試みます。Sanctumが受信HTTPリクエストを調べるとき、最初に認証クッキーをチェックし、存在しない場合は、Sanctumは有効なAPIトークンのAuthorizationヘッダを調べます。

SanctumをAPIトークン認証のみ、またはSPA認証のみに使用することはまったく問題ありません。Sanctumを使用しているからといって、Sanctumが提供する両方の機能を使用する必要があるわけではありません。

※Authorizationヘッダ・・・

クライアントがサイトにログインする際に入力した情報や、APIキー、トークンなどの認証情報が含まれているもの

※OAuth・・・

OAuthとは、複数のWebサービスを連携して動作させるために使われる仕組み。
通常、Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要があるが、OAuthを利用することでIDやパスワードを入力することなく、アプリケーション間の連動ができる。
参考:https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be

Inertia.jsとは

Inertia.jsとは?

LaravelなどのバックエンドフレームワークとVue.jsまたはReactなどのフロントエンドライブラリを統合するためのライブラリ。
Inertia.jsの主要な概念は、バックエンドでテンプレートをレンダリングし、そのテンプレート内でVue.jsまたはReactコンポーネントを使用する方法を提供する。
通常、LaravelのBladeテンプレートエンジンなどを使用してテンプレートをレンダリングし、Inertia.jsを使用してフロントエンドでインタラクティブコンポーネントを制御する。
これにより、SPAのようなユーザーエクスペリエンスを提供できる一方、バックエンドとフロントエンドをシームレスに統合できる。



以下、各サイトからの引用。

Inertiaは、基本的にクライアントサイドのルーティングライブラリです。ページ全体を再読み込みすることなく、ページを移動できます。移動は標準的なアンカータグの軽量ラッパー、コンポーネントによって実現します。
Inertiaのリンクをクリックすると、Inertiaがそのクリックを遮断し、XHRにリダイレクトします。これによって、ブラウザでページが再読み込みされることがなくなり、シングルページとしての挙動が確保できます。
https://kinsta.com/jp/blog/laravel-inertia/

Jetstreamが提供しているInertia.jsスタックは、テンプレート言語としてVue.jsを使います。
Inertiaアプリケーションの構築は、多くの部分が典型的なVueアプリケーションの構築と似ています。しかし、Vueのルータの代わりにLaravelのルータを使います。InertiaはLaravelコンポーネントデータの名前を提供することにより、LaravelのバックエンドからVueコンポーネントの単一ファイルをレンダーできるようにする小さなライブラリーです。
言い換えればこのスタックは、複雑なクライアントサイドのルーティングを使用せず、Vue.jsのフルパワーを提供します。今まで使ってきたLaravelの標準ルータが使用できます。
https://readouble.com/jetstream/1.0/ja/inertia.html

Inertia は従来のサーバー駆動型 Web アプリを構築するための新しいアプローチです。
Inertia にはクライアント側のルーティングがなく、API も必要ありません。いつものようにコントローラーとページビューを構築するだけです。Inertia はどのバックエンド フレームワークでもうまく機能しますが、Laravel用に微調整されています。
https://inertiajs.com/

用語集

自分の頭の整理の為の用語集。

MPA(Multi-Page Application)・・・

従来のウェブアプリケーションアーキテクチャ
各ページごとに新しいHTMLをサーバーからダウンロードして表示する。
ページごとにサーバーへのリクエストと完全なページの再読み込みが発生するため、遷移が遅いことがある。

SPA(Single-Page Application)・・・

1つのHTMLページを読み込み、JavaScriptを使用して動的なコンテンツを取得し、表示する。
ページ遷移時にサーバーへの新しいHTMLの要求がないため、遷移が速く、UXの向上が期待される。

CSR(Client-Side Rendering)・・・

CSRでは、ウェブページのコンテンツ生成および表示が、クライアント側のブラウザで行われる。
サーバーはクライアントに対して、HTMLのテンプレートとJavaScriptファイルを提供し、ページが読み込まれるとJavaScriptが実行され、コンテンツを動的に生成し、表示する。主にSPAと組み合わせて使用される。

SSR(Server-Side Rendering)・・・

サーバーでページを事前にレンダリングし、HTMLを生成してクライアントに提供する。
動的なコンテンツはクライアントで読み込まれる。
SSRは初期読み込みのパフォーマンスを向上させ、SEO対策に有効らしい。
MPAやSPAのいずれかと組み合わせて使用される。

SSG(Static Site Generation)・・・

SSGは、ビルド時にページを事前に生成し、静的なHTMLファイルを提供する。
データの変更がある場合は再ビルドが必要。
高速でセキュアで、CDN(Content Delivery Network)を使用してコンテンツを配信するのに適している。
MPAやSPAと組み合わせて使用される。

XHR・・・

XMLHttpRequest」の略称。
JavaScriptでHTTPリクエストを送信して、サーバーからデータを受信するために使用される技術。 主にAjax通信などで利用される。

ajax・・・

ウェブブラウザ内で非同期通信を行いながらインターフェイスの構築を行うプログラミング手法。
XMLHttpRequestによる非同期通信を利用し、通信結果に応じて動的にページの一部を書き換える。

「逆資本論」感想

井上純一さんの「逆資本論」を読みました。以前から読もうと思っていた本で、今回ようやく手に取りました。
以前の井上さんの経済漫画を全て読んでおり、今回も発売から時間が経ちましたが、読了しましたので感想を書いてみます。

今回の本は、前3冊とは異なり、経済だけでなく気候変動に関しても多くページが割かれていました。
これは著者の現状への危機感・経済対策を含む将来の展望において避けて通れない重要な議題であると感じました。

大筋としては、マルクスや「人新世の資本論」を書いた斎藤幸平氏の功績と共に誤りを挙げつつ、現実的な道筋について語っています。
具体的には資本主義の枠組みで気候変動対策が可能であると主張しており、その根拠や論拠を示しています。

一部の口コミでは、「個別の対策としては真っ当だと思うが、人生論の域には至っていないなと感じた」といった意見が見られました。
が、この本は人生論を探求したものではなく、あくまで現状の経済と気候変動に焦点を当て、その対策について述べたものだと思います。
(著者もそのつもりで書いてないはず。あくまでマルクスの「資本論」とは別物)

口コミでは特に以下が、本書について正確に評価しているように感じたので引用します。

井上先生は「中国嫁日記」で有名ですが、経済関連の単行本も何冊か出してまして、今回は世界史の授業で一度は聞いたことがあるだろうカール・マルクスの「資本論」がテーマで、これまでの単行本とは厚さからして違います。
最初に書いておきますと、タイトルが「逆資本論」とありますがアンチ共産主義の本ではありません。かと言って、共産主義万歳な本でもありません。
確かにソ連を始めとする共産主義国家は失敗しましたが、だからと言ってマルクスはすべて間違っているわけじゃないとは本書でも言及されています。そもそもマルクス資本論を書いたのは産業革命の時代、社会における格差と貧困の拡大が背景にあったのですが、これって現代にも当てはまりますよね? 更に現代は地球規模の気候問題もありまして、それらに対して私達はいかにすべきかを、資本論が書かれた時代背景から共産主義国家の誕生と失敗、現代の政治の諸問題なども絡めながら、マルクス経済学にヒントを求めたのがこちらの本なのです。
と、書いたらかなり固い本というイメージになると思いますが、漫画で分かりやすく説明してくれますからそこはご心配なく。
人類は歴史の中で少なからず間違いを犯して来ました。ですが同時に少なからず間違いを直して今日まで来たのです。
今回も、間違いがあればそれを直していけると信じています。

また、「れいわ新選組河野太郎、グレタさんを推している箇所で萎えた」という口コミもありますが、あくまでも「ある一方面では評価できる部分がある」と述べているにすぎず、別に推している訳ではないと個人的には感じました。
(ただ、個人的にはそもそもそこに言及する必要性は薄いようにも感じた)

いつも通り漫画でわかりやすく描かれているので、いきなり分厚い経済学の本に手を出すのが億劫な人にはもってこいの漫画だと思いますが、個人的には前3冊の方が発見が多かった印象です。
(著者が漫画やツイッターで紹介しているグリーンニューディール関連の本を事前に読んでいたというのもあるかも)

また、あえて物足りなく感じたポイントを挙げると

  • 再エネに関する箇所で、もう少し具体的な情報があるとよかった。欧州などで再エネに対する取り組みが加速しているのは分かるけど、日本でも欧州と同様の取り組みができる?現状どのような取り組みがなされている?また今後どのような取り組みが活発化されると想像できるか?など
  • 今回は気候変動に半分くらいボリュームを割いている印象なので(それだけ筆者が危機感を抱いているとも感じた)現在の日本で財政黒字化を目指すのはなぜ間違っているのかなどの説明が薄く、今回初めて井上さんの漫画を読んだ人はツイッターでよく見られるただの尖った意見(xx陰謀論)のようなものとして読んでしまう人もいるのでは?と感じた


著者の井上さんはいつも難しい経済学をわかりやすく漫画で伝えてくれているので個人的には好きですし、勉強させてもらっている部分も多いので、新刊出たらまた購入すると思います。
経済に興味がある人や「人新世の資本論」を読んだ人はぜひ読んでみてください。

useEffectとuseLayoutEffectの違いって結局なんや?

React勉強した人は通るであろう、useEffectとuseLayoutEffectの違いについて。
ググってみると色んなサイトで説明がありますが、自分なりに整理しました。

useEffectとuseLayoutEffectの違いについて

結論

→実行タイミングの違い。

useEffect

・非同期で実行
コンポーネントレンダリング後に非同期で実行されるため、コンポーネントの表示に影響を与えない操作に適している。
・使う局面としてはネットワークリクエスト、データの取得、DOMの変更、ログの出力などの遅延可能な操作を行うために適している。

useLayoutEffect

・同期的に実行
コンポーネントレンダリング後(仮想DOMの構築後)、DOMが更新される前に実行されるため、DOMの計算や計測、ブラウザでの描画前にスクロール位置を設定するなど、表示に関連する操作が必要な場合に使用する。
・ブラウザの描画前に実行されるため、useEffectだと発生する画面のちらつき(初期表示されてから瞬時にuseEffectによりブラウザが再描画する挙動)が避けられる。

※useEffectの画面のちらつきについては以下ブログでの説明が分かりやすいです。
useEffectのちらつきを無くしたいときの対処法【useLayoutEffect】

ただ、どのサイトでも説明されている通り、一般的にuseEffectを使うことが多く、useLayoutEffectを使う局面は限られている。

一般的にuseEffectが使われる理由

結論

→非同期による処理でユーザーエクスペリエンスを向上させつつ、アプリケーションのパフォーマンスを維持するため。

以下詳細。

非同期処理によるユーザーエクスペリエンスの向上

useEffectは非同期で実行されるので、コンポーネントレンダリングと関連する操作を遅延させない。
例えば、ネットワークリクエストやデータの取得など、時間がかかる操作を同期的に行うと、ユーザーがコンポーネントの表示を待たされることになり、ユーザーエクスペリエンスが悪化するが、useEffectは非同期に実行されるため、ユーザーエクスペリエンスを悪化を防ぐことができる。

パフォーマンス

useLayoutEffectは描画前に同期的な処理を行うため、コンポーネントレンダリングと関連する操作を遅延する可能性がある。
特に、複数のuseLayoutEffectが連続して呼ばれる場合、ブラウザの描画をブロックしてしまう可能性があるので、一般的なユースケースでは非同期操作(useEffect)が適切な場面であることが多い

useLayoutEffectの方が向いている局面

useEffectはブラウザでの描画が完了した後に非同期操作が実行されるため、コンポーネントの表示に直接影響を与えない操作(例: ログの出力)に適している。
ただし、ブラウザは非同期操作をキューに追加して実行しており、非同期処理の順序は保証されない。ので、操作の順序が重要な場合はuseLayoutEffectが使用される。

Reactでブラウザがレンダリングされるまでの流れ

1. 仮想DOMの構築(Render)

Reactコンポーネントレンダリングが行われ、仮想DOMが構築される。この段階では、まだ実際のDOMへの変更は行われない。

2. 実際のDOMへの変更(Reconciliation)

仮想DOMと前回のレンダリングの仮想DOMとの差分が計算され、必要なDOMの変更が特定される。この段階で実際のDOMへの変更が行われる。

3. ブラウザの描画(Painting)

DOMの変更が適用され、ブラウザが再描画を行なわれる。

まとめ

改めてuseEffectとuseLayoutEffectの実行タイミングの違いを確認

useEffect

→ブラウザの描画の後に非同期で実行される。

useLayoutEffect

→仮想DOMの構築が完了して、実際のDOMの変更の前に同期的に実行される。

大体のケースではuseEffectを使用するのが最適解。