ふみぽん's diary

技術的な備忘録が主のブログ

JavaScript入門①

JavaScript

 

JavaScriptの勉強をしたので備忘録として記事を書きます。

 

JavaScriptとは？

  • Google Chromeなどのブラウザで動くプログラム言語

　ブラウザで動くということでプログラム実装の際には、

　クライアントの環境を意識する必要がある。

 

　ちなみに、

　ブラウザの開発はECMAScript（JavaScriptの標準）を基に開発されています。

　

JavaScriptで何ができる？

　じゃ、JavaScriptで何ができるのかというと以下のようなことができます。

  • 計算ができる
  • HTMLやCSSを操作することができる
  • ユーザのクリックやマウスオーバーなどのアクションで何かを動かすことができる

 

JavaScriptで変数を使うには？

　他のブログラミング言語と同じく変数を扱います。

　JavaScriptでは変数宣言に以下を使います。

 

  • const
    値を一度代入した後、再代入することがない変数の宣言に用いる。

 

  • let

　　再代入の可能性がある変数の宣言に用いる。

 

  • var
    現在のJavaScript開発では使わないようです。
    昔はvarしかなかったので使っていたけど、バグの温床になることがある。
    varを改善したのがletと考えてよい。

 

　結論としては、

　constとletを使うべし！

　ちょい古めのコードを読んでいるとvarが登場してくることもあるかもね。。

 

　変数で使える文字は以下の通り

  • 半角アルファベット
  • 数字
  • アンダースコア「_」
  • ダラー「$」

　数字から始めることはNG

　もちろん予約語もNG

Spring FrameworkとSpring boot の違い

WEBアプリを開発するために使用したかったけど

 

そもそも両者の違いがさっぱりだったので

 

今後使用していく際のヒント程度にざっくり調べた。

 

その結果を以下に書き残しておく

 

 

Spring Frameworkとは

 

Spring bootとは

  • Spring Frameworkのデメリット「機能の使い分けが難しい」を解消するために作られたフレームワーク
  • つまり、最小限の設定と少ないコードでアプリケーションを開発するためのフレーム
  • ただ、Spring Frameworkを構成する一部分にすぎない

　（Spring  boot使いたい！てなったらSpring  Frameworkの知識も必要というわけ）

 

Apache Tomcatについて

Tomcat ApacheTomcat

ApacheTomcatについてあまり意識したことがなかったのですが、

Tomcatのディレクトリ構造を調べる機会があったので備忘録として。

 

Apache Tomcatとは

Apache：Webサーバの役割

Tomcat：サーブレットコンテナの役割（＋Webサーバもできなくはない）

 

つまり、

Webサーバとサーブレットコンテナの機能をもつソフトウェアで

サーブレットを動かすソフトウェアの1つである。

 

「サーブレットコンテナ」「Webサーバ」については以下参照

fumipow2317.hatenablog.com

 

 

ディレクトリ構造について

 

 

サーブレット＆ＪＳＰ用語ざっくり整理

サーブレット ＪＳＰ

 

サーバサイドプログラム

webサーバで動かすプログラムのこと。

ブラウザのリクエストによってwebサーバ上で動作し、

その実行結果をHTMLでレスポンスするようなプログラム。

Javaでサーバサイドプログラムを実行するには２種類の方法がある。

 

サーブレット

Javaを用いてサーバサイドプログラムを実行する技術のことをいう。

つまり、webサーバ上で動くJavaプログラムのこと。

ブラウザから実行できるサーブレットクラスを使用してサーバサイドプログラムを実現する。

 

サーブレットコンテナ 

サーブレットクラスの実行環境のことをいう。

サーブレット単体では、動けないのでサーブレットコンテナがサーブレットを動かす。

 

ＪＳＰ

サーブレットと同じく、Javaを用いてサーバサイドプログラムを実行する技術のことをいう。

webサーバ上で動くJavaプログラムであり、HTMLファイルとJavaプログラムが合体したもの。

JSPファイルのプログラムを使用してサーバサイドプログラムを実現する。

JSPファイルはサーブレットコンテナにより、サーブレットクラスに変換される。

 

webサーバ

HTTPを使ってブラウザと通信を行う。

プログラムを実行する機能は持っていない。

 

webアプリケーションサーバ　（Apache Tomcat）

webサーバの機能に加えて、プログラムを実行する機能を持っている。

特にサーブレットクラスの実行環境をサーブレットコンテナという。

Javaでwebアプリケーションを開発するには、サーブレットコンテナを持つアプリケーションサーバが必要となる。

オブジェクト指向〜カプセル化〜

Java オブジェクト指向

オブジェクト指向のカプセル化について

（現時点でわかっていることを書く）

 

カプセル化の意義

「他のクラスによって影響を受けてはいけない変数を扱うときの隠すための仕組み」

 

 

 

あるクラスについてカプセル化する

必要があるのかどうかを考える際に必要なこと

 

例）Carクラス

f:id:fumipow2317:20191006001714j:plain

 

①：Carクラスの外部からthis.fuelなどの方法でプロパティの値を取得する

②：アクセサメソッド（getter）を使ってプロパティの値を取得する

 

考慮する点：変更箇所

Carクラスのプロパティfuelの型がintからStringに変更になると

①の場合、取得値の型が変更になるので以下のような型修正をする必要がある。

変更前：int fuel = this.fuel

変更後：String fuel = this.String

この取得箇所が1000箇所あれば1000箇所の修正となる。

 

でも、

②の場合、アクセサメソッドの中でint型からString型に変換するメソッドとすれば

Carクラスが変更になっても「取得」する外部のクラスは関係ない！

もう少し詳しく書くと、型変換なんてアクセサメソッド（カプセルの中）で吸収して

解決するから外部のクラスは関係ない！

これぞ、カプセル化。

 

つまり、

変数の型などクラスの変更が発生する可能性があるクラスであればカプセル化して

修正時の影響範囲を狭めることができる。

あるクラスのプロパティの型がなんであろうとカプセル化すればアクセサメソッドで

プロパティの型と取得側の求める返却値の型の違いを吸収することができる

 

今回の例だけで言えば、

・Carクラスのプロパティは変更の可能性ない＋「取得」の箇所は数カ所

【プロパティとして扱ってもいいかも】

 

・Carクラスのプロパティの変更の可能性ある＋「取得」の箇所が膨大

【Carクラスカプセル化してアクセサメソッド経由でプロパティ扱おう】

 

 

また、わかったことがあれば書きます。。 

 

 

 

HTTPメソッド

HTTP web

HTTPの基本的なメソッド

以下の6つが主なメソッドだが、現実的にはGETとPOSTをよく使う

  1. GET
  2. POST
  3. PUT
  4. DELETE
  5. HEAD
  6. OPTION

 

CRUDとは

Create（作成）、Read（読み込み）、UPDATE（更新）、Delete（削除）を表し、

データ操作の基本処理のことをCRUD（クラッド）という。

 

CRUDとHTTPメソッドの対応関係

  • Create（作成）　→　POST／PUT
  • Read（読み込み）　→　GET
  • Uapdate（更新）　→　PUT
  • Delete（削除）　→　DELETE

 

１．GET

　リソースの取得
　指定したURIの情報を取得する。
　webページ、画像とかも取得可能。
 

２．POST

　リソースの作成、リソースの追加
 
　3つの役割を担う。
  • 子リソースの作成
　　あるリソースに対する子リソースの作成。
　　レスポンスは、「　201 Created　」
  • リソースへのデータの追加
　　既にあるリソースへデータを追加する。
　　レスポンスは　「　200 OK　」
　　（新規リソースの作成ではなく、追加なので201ではない）
 
  • 他のメソッドでは対応できない処理
　　通常、リソースの取得はGETでクエリパラメータをつけてGETするが…
　　実装上URIは2000文字とか上限がある。
　　そこで長すぎるクエリパラメータをリクエストボディにいれてPOSTする等。
 

３．PUT

　リソースの更新、リソースの作成
 
POSTとPUTの使い分け〜リソース作成時の使い分けについて〜
　　POSTで作成する場合、作成するリソースのURIはサーバが決定する。
　　PUTで作成する場合、作成するリソースのURIはクライアントが決定する。
　　上記を考えて決定すればオッケー。
　　しかしPUTで上書き注意すること。
　　特別理由なければ、リソースの作成はPOSTで行い
　　URIもサーバで決定してもらうほうがのぞましかったり。
 

４．DELETE

　リソースの削除
 

５．HEAD

　リソースのヘッダの取得
　　GETはリソースを取得するがリソースのヘッダのみ取得。
　　レスポンスにボディは含まれない。
　　なんとなくリソースの大きさわかったりする。
 

６．OPTION

　リソースがサポートしているHTTPメソッドの取得
 
 
 
 
現実にはGETとPOSTが1番使われる
→HTMLのフォームで指定できる
　メソッドであるからという制限に起因しているよう
 
 

HTTPのステートレス性

HTTP web

HTTPのステートレス性とはどういうことか？

ステートレス性とは
　サーバがクライアントのアプリケーション状態を
　覚えておかないということ（保存しない）
 
 
アプリケーション状態とは、セッション状態のこと。
セッションとは、
　システムにログインしてからログアウトするまでの一覧の操作のことをまとめていう
 
つまり、HTTPは
クライアントがアプリケーション状態を覚えて、サーバに送信するので成り立つ
 
しかし、
　リクエストの度にアプリケーション状態を全て伝えることになるので
　送信するデータが増えることになる。。。。
 
ログイン情報（ユーザ名・パスワード）をリクエストの度に送信する必要がある
アプリケーションであれば、認証を繰り返すことになりサーバに負荷がかかる。　
 
 
その結果、パフォーマンスが低下することにもなりうる。
これがステートレス性のデメリットである。