- 投稿日:2020-02-21T13:16:50+09:00
RailsでHamlを使う方法⭐︎
RailsでHamlを使えるようにする方法
復習がてらにhamlを使ってコーディングしていたのでこの際アウトプットしておきます。
手順↓
- hamlのgemをインストールする
- 拡張子をerbからhamlにする
以上。超簡単
Hamlのgemをインストールする
Gemfilegem 'haml-rails'Gemfileに以上の記載をして
ターミナルで必ずbundle install
を実行しましょう。$ bundle installこの時点でhamlは使えるようになりますが拡張子も一気にerbからhamlに変更しておくと便利なので実行します。
拡張子の変更をターミナルで実行する
$ rails haml:erb2haml実行するとターミナル上で何か聞かれますが
y
コマンドを押しておくとオッケーです。以上。簡単
- 投稿日:2020-02-21T11:30:54+09:00
「Webを支える技術」読書録 1部
https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%E3%80%81URI%E3%80%81HTML%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus/dp/4774142042
を読んだので、自分の言葉でのまとめです
長いので1部につき1ページにまとめます。
「本書の構成」とかは飛ばしてます。1部 Web概論
1章 Webとは何か
1.1 全ての基盤であるWeb
現在のコンピュータでもっとも重要なソフトウェアはブラウザ。
色々なサービスにWebを通じてアクセスしている。1.2 さまざまなWebの用途
次の3つがある
・Webサイト
もっとも身近な例。Webサイトの構成は様々だが、ユーザーからすればそれを気にしなくて済むことがWebの大きな特徴・ユーザーインターフェースとしてのWeb
設定画面にブラウザを使っている例や、HTMLでのヘルプ記事の例が挙げられる・APIとしてのWeb
プログラム上でデータをやり取りするためのもの。データにはプログラムが解釈しやすいxmlやjsonが使われる。1.3 Webを支える技術
Webを構築する技術的要素は大きく分けて下記
HTTP、URI、HTML
URIはページを指し示すために、HTMLはサイトの情報を表現する文書フォーマットとして、HTTPは情報のやり取りにそれぞれ使われる。
これらはとてもシンプルな技術で、これらに支えられたWebはハイパーメディアシステムと分散システムの2つの側面を持っているハイパーメディア
テキストや画像、音声、映像などをハイパーリンク(あるいは単にリンクとも呼ばれる)で結びつけて構成したシステムのこと。
ユーザーが非線形にリンクを洗濯して情報を取得できる
Webには他のWebページや画像、映像へのリンクが含まれるためハイパーメディアの一例。分散システム
複数のコンピュータをつなげて情報処理させるシステムのこと。
複数台のパワーが使えるので膨大な処理も可能になる
Webも膨大なものなので、この分散システムが使われており、プロトコルがシンプルなため、これだけの規模のシステムが実現できている。第2章 Webの歴史
2.1 Web以前のインターネット
初期のインターネットにはWebが存在せず、当時はTCP/IPに加えバケツリレー式のUUCPもあったため、単にメールを送るだけでも遅延があった。
このときのアプリケーションは
- FTP(ファイル交換)
- telnet(UNIXホストにリモート接続)
- Gopher(コンテンツを簡単に公開するためのアプリ)
など
2.2 Web以前のハイパーメディア
Memex
1945年に発表。ハイパーメディアの起源
システムでなく構想だが、電気的に接続した本やフィルムを相互リンクし、それをたどって次々に表示するという現在のWebに似たものだった。
これがのちに影響を与えた。Xanadu
1965年、Nelsonがハイパーメディアとハイパーテキストという言葉を考案。
現在のWebをさらに進化させた機能を持つXanaduを構想し開発を始めたが、複雑すぎて頓挫HyperCard
1987年にBill AtkinsonがAppleで開発。
「カード」と呼ばれる文書を単位にして相互にリンクを貼り、スクリプト言語HtperTalkによるプログラムを実行できるスタンドアロンのWebサービス。
成功し、初の実用的なハイパーメディアになった。Web以前のハイパーメディアの問題点
Webはもっとも普及したハイパーメディアの実装となった。
Googleのページランク、トラックバックもリンクを前提に設計されている
ただ、単方向リンクしかサポートしていない、リンク切れの可能性がある、バージョン管理やトランスクルージョンの機能がないなどから不完全なハイパーメディアとする声もある。
それでも成功した要因としては必要最低限のリンク機能だけを備えていたことがある。
Web以前のハイパーメディアの問題点は複雑すぎたこと。2.3 Web以前の分散システム
初期のコンピュータは科学技術計算などの専門目的で作られていた。
1960年代にメインフレームが開発され、複数の目的で使用できるようになった。このころの利用形態はホストコンピュータに端末を接続し、ホストコンピュータで集中的に処理するというもの。
1970年代以降、ダウンサイズが進み1つ1つのコンピュータの性能が上がったことで複数のコンピュータを組み合わせて処理を分散させる手法が登場する。RPC
リモートのサーバーで実行しているプログラムをクライアント側から呼び出せる。
有名なものとしてはSunRPC、アポロ、DCE
このころ(1980年代後半)はUNIXベンダーによる競争が激しく、各社とも自社の分散システムを標準にしようとしていたCORBA、DCOM
RPCは関数を呼び出す仕組みだったが、オブジェクト自体をリモート側に配置する「分散オブジェクト」と呼ばれる技術が考案された。
代表例はCORBA。Microsoftは対抗してDCOMを開発。
どちらもIDL(Interface Definition Langage)でオブジェクトのメソッドを定義、実装ではネットワーク越しにシリアライズしたメッセージを交換する。
この点ではRPCと同じ。
ただ汎用的なオブジェクト機能を実現しようとした結果、非常に複雑な仕様となり、CORBAとDCOMの間の互換性もなかった。Web以前の分散システムの問題点
RPCは今でもNFSなどの実装に使われているが、現実的に動作するのは通信相手がある程度決まっているイントラネット環境まで。
大規模な異種分散環境では動作しない。それは次の問題がRPCシステムに共通して存在するから。
- 性能劣化の問題:ネットワーク越しに関数を呼び出すのは同一プロセス内で行うのと比べて何倍も時間がかかる。しかも一般に関数の粒度が小さいため、何回も呼び出しする必要がある。
- データ型変換の問題:プログラミングごとにサポートするデータ型が異なるため、複数の言語が混在してるとバグる
- インターフェースバージョンアップ時の互換性の問題: サーバーのインターフェースを更新した場合、古いクライアントに対して下位互換性を保てない
- 負荷分散の問題:サーバー上にクライアントのアプリケーション状態を保存するため、サーバー間で状態を共有しなければならず、多数のサーバーで負荷分散するのが難しい。
2.4 Webの誕生
1980年代までにハイパーメディア構想が生まれ、インターネットが登場し、分散システムが構築されたタイミングでWebが生まれた。
1990年にTim Barners-LeeがWebの提案書を書き、同年のクリスマス休暇にブラウザとサーバーを完成させた。
これ以降Webが普及し始め、1993年にイリノイ大学のNSCAがブラウザMosaicを公開。これがWebの普及を一気に推し進めた。
Mosaicは本文にインラインで画像を混在させることができ、現在のIEやFirefoxの源流になっているハイパーメディアとしてのWeb
Webはそれ以前のハイパーメディアとは違い、インターネットを使ったハイパーメディアとして設計された。
そのため不特定多数の情報をリンクさせ合うことができ、システムを大規模化しやすいという利点を持つ。
反面、情報の集中的な管理は難しいためリンク切れを起こしやすい。
もう一つの特徴は単方向リンクだけであること。
もともとリンクの概念では外部からリンクを取り込むという拡張リンクの考え方もあり、Webにそれを取り込もうとした動きもあったが結局単方向リンクのみが使われている。
ユーザーにとってはわかりやすく、かつ実装しやすいためここまで普及したと言える。分散システムとしてのWeb
RPCは閉じたネットワーク環境で決まった相手と通信する上では優れているが、逆にオープンな環境で不特定多数のクライアントにサービスを提供するのには向いていない。
これに向いているシステムがWeb。
OSやハードウェアがバラバラでも問題ないのはHTTPというシンプルなプロトコルに固定したため。2.5 Webの標準化
Webの仕様策定
Web以前のインターネット標準は全てIETFとして定められていたが、Webの普及のスピードにIETFでの仕様策定が追いつかず、各社で相互運用性に欠ける状態が発生した。
そのためHTTPとURIとHTMLの標準化が求められ、Tim Barners-LeeがW3Cを設立。
W3CによってHTML, XML, HTTP, URI, CSSなどの標準化作業が行われた。RESTの誕生
また、Baebers-Leeと共にHTTP1.0とHTTP1.1の仕様策定に関わったRoy FieldingがWebの分析を行い、1つのアーキテクチャスタイルとしてまとめ、これを「REST」と名付けた。
さまざまなハイパーメディアフォーマットの誕生
初期のWebではHTMLが唯一のハイパーメディアフォーマットだったが、その後もHTMLで対応できない要望が出てくるにつれて新しいハイパーメディアフォーマットが誕生した。
HTMLに様々な意味を持たせるmicroformat、Webページの新着情報をサーバーで配信、それをチェックするRSSが提案された
(RSSについては最終的にIETFでAtomが標準化される。)
HTMLやAtomはXMLベースのため表記が冗長すぎるためより単純なデータフォーマットがいくつか提案された。
その中でJSONがデファクトスタンダードとなった。2.6 Web APIを巡る議論
Webの用途が多様化するとプログラムから自動処理を行いたいという要望が出始める。
1990年代後半から2000年代前半にかけてWeb APIの議論が起こった。SOAPとWS-*
様々なグループがWebをプログラムから利用できるように拡張しようとした。
特に大きかったのがRPC/分散オブジェクトのグループで、RPCと同じ方法論でWeb上の分散オブジェクトを実現しようとした。
基本的なプロトコルはSOAPで、これはHTTPをアプリケーションプロトコルでなくトランスファープロトコルとして扱い、HTTP上で独自のメッセージを転送する。
これはメッセージ転送の方法だけを定めた仕様なので、サービスごとのプロトコルも定義しなくてはならない。
これを各社ばらばらに定義するとまた失敗するため、WS-Security、WS-TransactoinなどWS-*と呼ばれる仕様群が次々に提案された。
が、同じような仕様が複数乱立したためまた標準化競争が起こった。SOAP 対 REST
SOAPとRESTに関する論争は2003年ごろがピークだったよう。
RESTの普及に弾みをつけたのは2002年に登場したAmazon Webサービスだった。
Amazonは自社が扱う書籍やそのほかの商品の情報をWebを通じてプログラムから取得できるようにした
その際、SOAPを用いた形式とURIをHTTPでGETする形式(便宜上、REST形式と呼ばれた)の二つを用意した。
その結果、SOAP:RESTの利用比率が20:80だったことで論争が激化。
また、2004年から始まったWeb2.0の流れの中でGoogleやAmazonがREST形式のWeb APIを提供し始める。
ここで重要だったのはいろいろなAPIが提供する情報を組み合わせて1つのアプリケーションを実現するマッシュアップという手法。
ここで手軽さが求められ、最終的にRESTスタイルの方が受け入れられていった。SOAPとWS-*の敗因
SOAPとWS-*の問題点としては、RPCの技術的問題点をさらに広げてしまったことと、SOAPが標準として確定しないうちに各社が実装を始めてしまい、結果的に相互運用性に欠けたことがあげられる。
2.7 すべてがWebへ
RESTが普及してくのに並行してユーザーインターフェースはWebで統一され始め、エンドユーザはWebだけを意識するようになった
背景にajaxとCometなどの技術的ブレークスルーがある。
これによりユーザーイインターフェースの使い勝手が向上しつつある。
例えば、以前はローカルに保存するしかなかった地図データをリモートからとってくることにより、全世界の衛星写真を最新の状態で利用できる。
サーバー側では地図データをまとめて保管し、必要に応じて画像をダウンロードしてるからこそ実現できる。第3章 REST
3.1 アーキテクチャスタイルの重要性
RESTはWebのアーキテクチャスタイル。
アーキテクチャスタイルとは、複数のアーキテクチャに共通する性質、様式、作法、流儀を指す言葉。
具体的には、MVC、パイプ&フィルタ、イベントシステムなど
実際にアーキテクチャを構築する際の指針になるもので、とても重要3.2 アーキテクチャスタイルとしてのREST
Webのアーキテクチャスタイルはクライアント/サーバーでもあり、RESTでもある。
RESTはクライアント/サーバーにいくつかの制約をつけて構築されたスタイル。
ソフトウェアアーキテクチャはコンポーネントを組み合わせて実現するが、その動作を協調させるために制約が必要
よって、個別だろうがアーキテクチャスタイルを守ることが大事
以降、RESTの実装例としてWebを用いる3.3 リソース
RESTにおける重要な概念の一つにリソースがある。
リソースは「Web上に存在する名前を持ったあらゆる情報」のこと。
リソースが名前を持つことで一意に区別できるようになる。リソースの名前としてのURI
この一意の名前というのがURI。
これを使うことでほかのリソースと区別してアクセスすることが可能になる。
URIが備える「リソースを簡単にさししめる性質」のことを「アドレス可能性」という。1つのリソースは複数のURIを持てる。
複数つけることでクライアントがアクセスしやすくなるが、反面どれが正式なURIかがわかりにくくなるリソースの表現と状態
クライアントとサーバーで通信するときは具体的なデータを送信し合うことになるが、このときやり取りするデータを「リソースの表現」という。
一つのリソースは複数の表現を持てる。
また、リソースには状態があり、それが変化すると表現も変化する。3.4 スタイルを組み合わせてRESTを構築する
クライアント/サーバー
WebはHTTPというプロトコルでクライアントとサーバーが通信するクライアント/サーバーのアーキテクチャスタイルを採用している。
クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返す。
利点としては処理をクライアントとサーバーに分割できること。
これによってクライアント側をマルチプラットフォームにできる。
クライアント側ではユーザーインターフェースを担当することでサーバー側ではデータを送るだけで良くなる。
また、複数のサーバーを組み合わせて冗長性をあげることで可用性もあげられる。
このクライアント/サーバーにスタイルを追加していくことでRESTを構築する。
下記に追加するスタイルと特徴を挙げる。ステートレスサーバー
クライアントの状態をサーバーで管理しないことで、サーバー側の実装を簡略化できる。
簡略化することでクライアントからのリクエストに答えた後すぐに計算機リソースを解放できる。
しかし現実にはステートレスでないサーバーが多く存在する。代表例としてはCookieを使っているサーバー。
もちろんCookieならではの利点もあるので必ずしも排除する必要はないが、スタイルに反することは事実。
使うならそのことを理解した上で、必要最小限で使うべき。キャッシュ
リソースの鮮度に基づいて一度取得したリソースをクライアント側で使い回す。
こうすることで通信の手間を省き、より効率的な処理ができるが、反面情報の信頼度が落ちる統一インターフェース
URIで指し示したリソースに対する操作を統一した限定的なインターフェースで行うスタイルのこと。
例えばHTTP1.1では8つのメソッドのみが定義されており、通常それ以上増やせない。
こうしてインタフェースの柔軟性に制約を加えることで全体のアーキテクチャがシンプルになる。
Webが多様なクライアントやサーバーの実装で構成できているのは、統一インターフェースが一役買っている。階層化システム
統一インターフェースによりシステムが階層化しやすくなる。
クライアントとサーバーの間にロードバランサやプロキシを噛ませても、サーバーにもプロキシにも同じプロトコルでアクセスできるのでクライアント側では接続先を意識する必要がなくなる。コードオンデマンド
プログラムをサーバーからダウンロードし、クライアント側でそれを実行するスタイル。
例えばjsvascriptやFlash、javaアプレッドなどが該当する。
利点としてはクライアント側を後から拡張できること。
ただし、プログラムをクライアント側で実行してしまうことでアプリケーションプロトコルの可視性は低下する。REST
ここまで追加したアーキテクチャスタイルをRESTと呼ぶ。
上述した通り一つ二つ違反する(=スタイルを除外する)分には構わないが、ほとんど除外するならほかのアーキテクチャスタイルを検討すべき。
例えばP2Pは代表的なRESTでないアーキテクチャスタイル。3.5 RESTの二つの側面
ハイパーメディア、分散システム両方の面でRESTとの関係を考える
RESTとハイパーメディア
Webではリンクをいくつか辿ることで機能を実現している。
この特徴をRESTでは「アプリケーション状態エンジンとしてのハイパーメディア」と呼ぶ
例えばブックマークアプリであればユーザーが「ブックマーク一覧を表示してる」「新しいブックマークを追加しようとしている。」といった状態がある。
この状態はリンクを辿ることによって遷移する。
このようなハイパーメディアを用いたアプリケーションには、リソースのURIがわかればほかのアプリケーションでもリソースを再利用できるという利点がある。
リソースをリンクで接続することで1つのアプリケーションを構成するという考え方はRESTの基幹をなす思想で、「接続性」とも呼ばれるRESTと分散システム
RPCは先述した通り、多くの関数を呼び出すためシステム全体の性能劣化を引き起こす。
対してRESTではリソース同士をリンクで辿ることでアプリケーションを実現する。
このリソースはRPCでやり取りするデータよりも粒度が大きいため、全体として性能劣化を抑えられる。
また、RPCでは互換性の問題もあったがRESTでは統一インターフェースが使われてるため、マイナーバージョンアップ程度では互換性の問題が発生しない。3.6 RESTの意義
RESTはWeb全体のアーキテクチャスタイルであり、RESTという理論があったからこそWebは成功している。
WebサービスがRESTfulになればWeb全体が良くなるので、Webサービスを作る際は意識するべき私見
今使われている技術の勝因、使われていない技術の敗因を知ることでどのような技術が求められるかがわかりました。
特にアーキテクチャスタイルを守ることで色々なメリットがあるので意識して設計に活かします
- 投稿日:2020-02-21T11:30:54+09:00
「Webを支える技術」読書録 1部 Web概論
https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%E3%80%81URI%E3%80%81HTML%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus/dp/4774142042
を読んだので、自分の言葉でのまとめです
長いので1部につき1ページにまとめます。
「本書の構成」とかは飛ばしてます。1章 Webとは何か
1.1 全ての基盤であるWeb
現在のコンピュータでもっとも重要なソフトウェアはブラウザ。
色々なサービスにWebを通じてアクセスしている。1.2 さまざまなWebの用途
次の3つがある
・Webサイト
もっとも身近な例。Webサイトの構成は様々だが、ユーザーからすればそれを気にしなくて済むことがWebの大きな特徴・ユーザーインターフェースとしてのWeb
設定画面にブラウザを使っている例や、HTMLでのヘルプ記事の例が挙げられる・APIとしてのWeb
プログラム上でデータをやり取りするためのもの。データにはプログラムが解釈しやすいxmlやjsonが使われる。1.3 Webを支える技術
Webを構築する技術的要素は大きく分けて下記
HTTP、URI、HTML
URIはページを指し示すために、HTMLはサイトの情報を表現する文書フォーマットとして、HTTPは情報のやり取りにそれぞれ使われる。
これらはとてもシンプルな技術で、これらに支えられたWebはハイパーメディアシステムと分散システムの2つの側面を持っているハイパーメディア
テキストや画像、音声、映像などをハイパーリンク(あるいは単にリンクとも呼ばれる)で結びつけて構成したシステムのこと。
ユーザーが非線形にリンクを洗濯して情報を取得できる
Webには他のWebページや画像、映像へのリンクが含まれるためハイパーメディアの一例。分散システム
複数のコンピュータをつなげて情報処理させるシステムのこと。
複数台のパワーが使えるので膨大な処理も可能になる
Webも膨大なものなので、この分散システムが使われており、プロトコルがシンプルなため、これだけの規模のシステムが実現できている。第2章 Webの歴史
2.1 Web以前のインターネット
初期のインターネットにはWebが存在せず、当時はTCP/IPに加えバケツリレー式のUUCPもあったため、単にメールを送るだけでも遅延があった。
このときのアプリケーションは
- FTP(ファイル交換)
- telnet(UNIXホストにリモート接続)
- Gopher(コンテンツを簡単に公開するためのアプリ)
など
2.2 Web以前のハイパーメディア
Memex
1945年に発表。ハイパーメディアの起源
システムでなく構想だが、電気的に接続した本やフィルムを相互リンクし、それをたどって次々に表示するという現在のWebに似たものだった。
これがのちに影響を与えた。Xanadu
1965年、Nelsonがハイパーメディアとハイパーテキストという言葉を考案。
現在のWebをさらに進化させた機能を持つXanaduを構想し開発を始めたが、複雑すぎて頓挫HyperCard
1987年にBill AtkinsonがAppleで開発。
「カード」と呼ばれる文書を単位にして相互にリンクを貼り、スクリプト言語HtperTalkによるプログラムを実行できるスタンドアロンのWebサービス。
成功し、初の実用的なハイパーメディアになった。Web以前のハイパーメディアの問題点
Webはもっとも普及したハイパーメディアの実装となった。
Googleのページランク、トラックバックもリンクを前提に設計されている
ただ、単方向リンクしかサポートしていない、リンク切れの可能性がある、バージョン管理やトランスクルージョンの機能がないなどから不完全なハイパーメディアとする声もある。
それでも成功した要因としては必要最低限のリンク機能だけを備えていたことがある。
Web以前のハイパーメディアの問題点は複雑すぎたこと。2.3 Web以前の分散システム
初期のコンピュータは科学技術計算などの専門目的で作られていた。
1960年代にメインフレームが開発され、複数の目的で使用できるようになった。このころの利用形態はホストコンピュータに端末を接続し、ホストコンピュータで集中的に処理するというもの。
1970年代以降、ダウンサイズが進み1つ1つのコンピュータの性能が上がったことで複数のコンピュータを組み合わせて処理を分散させる手法が登場する。RPC
リモートのサーバーで実行しているプログラムをクライアント側から呼び出せる。
有名なものとしてはSunRPC、アポロ、DCE
このころ(1980年代後半)はUNIXベンダーによる競争が激しく、各社とも自社の分散システムを標準にしようとしていたCORBA、DCOM
RPCは関数を呼び出す仕組みだったが、オブジェクト自体をリモート側に配置する「分散オブジェクト」と呼ばれる技術が考案された。
代表例はCORBA。Microsoftは対抗してDCOMを開発。
どちらもIDL(Interface Definition Langage)でオブジェクトのメソッドを定義、実装ではネットワーク越しにシリアライズしたメッセージを交換する。
この点ではRPCと同じ。
ただ汎用的なオブジェクト機能を実現しようとした結果、非常に複雑な仕様となり、CORBAとDCOMの間の互換性もなかった。Web以前の分散システムの問題点
RPCは今でもNFSなどの実装に使われているが、現実的に動作するのは通信相手がある程度決まっているイントラネット環境まで。
大規模な異種分散環境では動作しない。それは次の問題がRPCシステムに共通して存在するから。性能劣化の問題
ネットワーク越しに関数を呼び出すのは同一プロセス内で行うのと比べて何倍も時間がかかる。しかも一般に関数の粒度が小さいため、何回も呼び出しする必要がある。
データ型変換の問題
プログラミングごとにサポートするデータ型が異なるため、複数の言語が混在してるとバグる
インターフェースバージョンアップ時の互換性の問題
サーバーのインターフェースを更新した場合、古いクライアントに対して下位互換性を保てない
負荷分散の問題
サーバー上にクライアントのアプリケーション状態を保存するため、サーバー間で状態を共有しなければならず、多数のサーバーで負荷分散するのが難しい。
2.4 Webの誕生
1980年代までにハイパーメディア構想が生まれ、インターネットが登場し、分散システムが構築されたタイミングでWebが生まれた。
1990年にTim Barners-LeeがWebの提案書を書き、同年のクリスマス休暇にブラウザとサーバーを完成させた。
これ以降Webが普及し始め、1993年にイリノイ大学のNSCAがブラウザMosaicを公開。これがWebの普及を一気に推し進めた。
Mosaicは本文にインラインで画像を混在させることができ、現在のIEやFirefoxの源流になっているハイパーメディアとしてのWeb
Webはそれ以前のハイパーメディアとは違い、インターネットを使ったハイパーメディアとして設計された。
そのため不特定多数の情報をリンクさせ合うことができ、システムを大規模化しやすいという利点を持つ。
反面、情報の集中的な管理は難しいためリンク切れを起こしやすい。
もう一つの特徴は単方向リンクだけであること。
もともとリンクの概念では外部からリンクを取り込むという拡張リンクの考え方もあり、Webにそれを取り込もうとした動きもあったが結局単方向リンクのみが使われている。
ユーザーにとってはわかりやすく、かつ実装しやすいためここまで普及したと言える。分散システムとしてのWeb
RPCは閉じたネットワーク環境で決まった相手と通信する上では優れているが、逆にオープンな環境で不特定多数のクライアントにサービスを提供するのには向いていない。
これに向いているシステムがWeb。
OSやハードウェアがバラバラでも問題ないのはHTTPというシンプルなプロトコルに固定したため。2.5 Webの標準化
Webの仕様策定
Web以前のインターネット標準は全てIETFとして定められていたが、Webの普及のスピードにIETFでの仕様策定が追いつかず、各社で相互運用性に欠ける状態が発生した。
そのためHTTPとURIとHTMLの標準化が求められ、Tim Barners-LeeがW3Cを設立。
W3CによってHTML, XML, HTTP, URI, CSSなどの標準化作業が行われた。RESTの誕生
また、Baebers-Leeと共にHTTP1.0とHTTP1.1の仕様策定に関わったRoy FieldingがWebの分析を行い、1つのアーキテクチャスタイルとしてまとめ、これを「REST」と名付けた。
さまざまなハイパーメディアフォーマットの誕生
初期のWebではHTMLが唯一のハイパーメディアフォーマットだったが、その後もHTMLで対応できない要望が出てくるにつれて新しいハイパーメディアフォーマットが誕生した。
HTMLに様々な意味を持たせるmicroformat、Webページの新着情報をサーバーで配信、それをチェックするRSSが提案された
(RSSについては最終的にIETFでAtomが標準化される。)
HTMLやAtomはXMLベースのため表記が冗長すぎるためより単純なデータフォーマットがいくつか提案された。
その中でJSONがデファクトスタンダードとなった。2.6 Web APIを巡る議論
Webの用途が多様化するとプログラムから自動処理を行いたいという要望が出始める。
1990年代後半から2000年代前半にかけてWeb APIの議論が起こった。SOAPとWS-*
様々なグループがWebをプログラムから利用できるように拡張しようとした。
特に大きかったのがRPC/分散オブジェクトのグループで、RPCと同じ方法論でWeb上の分散オブジェクトを実現しようとした。
基本的なプロトコルはSOAPで、これはHTTPをアプリケーションプロトコルでなくトランスファープロトコルとして扱い、HTTP上で独自のメッセージを転送する。
これはメッセージ転送の方法だけを定めた仕様なので、サービスごとのプロトコルも定義しなくてはならない。
これを各社ばらばらに定義するとまた失敗するため、WS-Security、WS-TransactoinなどWS-*と呼ばれる仕様群が次々に提案された。
が、同じような仕様が複数乱立したためまた標準化競争が起こった。SOAP 対 REST
SOAPとRESTに関する論争は2003年ごろがピークだったよう。
RESTの普及に弾みをつけたのは2002年に登場したAmazon Webサービスだった。
Amazonは自社が扱う書籍やそのほかの商品の情報をWebを通じてプログラムから取得できるようにした
その際、SOAPを用いた形式とURIをHTTPでGETする形式(便宜上、REST形式と呼ばれた)の二つを用意した。
その結果、SOAP:RESTの利用比率が20:80だったことで論争が激化。
また、2004年から始まったWeb2.0の流れの中でGoogleやAmazonがREST形式のWeb APIを提供し始める。
ここで重要だったのはいろいろなAPIが提供する情報を組み合わせて1つのアプリケーションを実現するマッシュアップという手法。
ここで手軽さが求められ、最終的にRESTスタイルの方が受け入れられていった。SOAPとWS-*の敗因
SOAPとWS-*の問題点としては、RPCの技術的問題点をさらに広げてしまったことと、SOAPが標準として確定しないうちに各社が実装を始めてしまい、結果的に相互運用性に欠けたことがあげられる。
2.7 すべてがWebへ
RESTが普及してくのに並行してユーザーインターフェースはWebで統一され始め、エンドユーザはWebだけを意識するようになった
背景にajaxとCometなどの技術的ブレークスルーがある。
これによりユーザーイインターフェースの使い勝手が向上しつつある。
例えば、以前はローカルに保存するしかなかった地図データをリモートからとってくることにより、全世界の衛星写真を最新の状態で利用できる。
サーバー側では地図データをまとめて保管し、必要に応じて画像をダウンロードしてるからこそ実現できる。第3章 REST
3.1 アーキテクチャスタイルの重要性
RESTはWebのアーキテクチャスタイル。
アーキテクチャスタイルとは、複数のアーキテクチャに共通する性質、様式、作法、流儀を指す言葉。
具体的には、MVC、パイプ&フィルタ、イベントシステムなど
実際にアーキテクチャを構築する際の指針になるもので、とても重要3.2 アーキテクチャスタイルとしてのREST
Webのアーキテクチャスタイルはクライアント/サーバーでもあり、RESTでもある。
RESTはクライアント/サーバーにいくつかの制約をつけて構築されたスタイル。
ソフトウェアアーキテクチャはコンポーネントを組み合わせて実現するが、その動作を協調させるために制約が必要
よって、個別だろうがアーキテクチャスタイルを守ることが大事
以降、RESTの実装例としてWebを用いる3.3 リソース
RESTにおける重要な概念の一つにリソースがある。
リソースは「Web上に存在する名前を持ったあらゆる情報」のこと。
リソースが名前を持つことで一意に区別できるようになる。リソースの名前としてのURI
この一意の名前というのがURI。
これを使うことでほかのリソースと区別してアクセスすることが可能になる。
URIが備える「リソースを簡単にさししめる性質」のことを「アドレス可能性」という。1つのリソースは複数のURIを持てる。
複数つけることでクライアントがアクセスしやすくなるが、反面どれが正式なURIかがわかりにくくなるリソースの表現と状態
クライアントとサーバーで通信するときは具体的なデータを送信し合うことになるが、このときやり取りするデータを「リソースの表現」という。
一つのリソースは複数の表現を持てる。
また、リソースには状態があり、それが変化すると表現も変化する。3.4 スタイルを組み合わせてRESTを構築する
クライアント/サーバー
WebはHTTPというプロトコルでクライアントとサーバーが通信するクライアント/サーバーのアーキテクチャスタイルを採用している。
クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返す。
利点としては処理をクライアントとサーバーに分割できること。
これによってクライアント側をマルチプラットフォームにできる。
クライアント側ではユーザーインターフェースを担当することでサーバー側ではデータを送るだけで良くなる。
また、複数のサーバーを組み合わせて冗長性をあげることで可用性もあげられる。
このクライアント/サーバーにスタイルを追加していくことでRESTを構築する。
下記に追加するスタイルと特徴を挙げる。ステートレスサーバー
クライアントの状態をサーバーで管理しないことで、サーバー側の実装を簡略化できる。
簡略化することでクライアントからのリクエストに答えた後すぐに計算機リソースを解放できる。
しかし現実にはステートレスでないサーバーが多く存在する。代表例としてはCookieを使っているサーバー。
もちろんCookieならではの利点もあるので必ずしも排除する必要はないが、スタイルに反することは事実。
使うならそのことを理解した上で、必要最小限で使うべき。キャッシュ
リソースの鮮度に基づいて一度取得したリソースをクライアント側で使い回す。
こうすることで通信の手間を省き、より効率的な処理ができるが、反面情報の信頼度が落ちる統一インターフェース
URIで指し示したリソースに対する操作を統一した限定的なインターフェースで行うスタイルのこと。
例えばHTTP1.1では8つのメソッドのみが定義されており、通常それ以上増やせない。
こうしてインタフェースの柔軟性に制約を加えることで全体のアーキテクチャがシンプルになる。
Webが多様なクライアントやサーバーの実装で構成できているのは、統一インターフェースが一役買っている。階層化システム
統一インターフェースによりシステムが階層化しやすくなる。
クライアントとサーバーの間にロードバランサやプロキシを噛ませても、サーバーにもプロキシにも同じプロトコルでアクセスできるのでクライアント側では接続先を意識する必要がなくなる。コードオンデマンド
プログラムをサーバーからダウンロードし、クライアント側でそれを実行するスタイル。
例えばjsvascriptやFlash、javaアプレッドなどが該当する。
利点としてはクライアント側を後から拡張できること。
ただし、プログラムをクライアント側で実行してしまうことでアプリケーションプロトコルの可視性は低下する。REST
ここまで追加したアーキテクチャスタイルをRESTと呼ぶ。
上述した通り一つ二つ違反する(=スタイルを除外する)分には構わないが、ほとんど除外するならほかのアーキテクチャスタイルを検討すべき。
例えばP2Pは代表的なRESTでないアーキテクチャスタイル。3.5 RESTの二つの側面
ハイパーメディア、分散システム両方の面でRESTとの関係を考える
RESTとハイパーメディア
Webではリンクをいくつか辿ることで機能を実現している。
この特徴をRESTでは「アプリケーション状態エンジンとしてのハイパーメディア」と呼ぶ
例えばブックマークアプリであればユーザーが「ブックマーク一覧を表示してる」「新しいブックマークを追加しようとしている。」といった状態がある。
この状態はリンクを辿ることによって遷移する。
このようなハイパーメディアを用いたアプリケーションには、リソースのURIがわかればほかのアプリケーションでもリソースを再利用できるという利点がある。
リソースをリンクで接続することで1つのアプリケーションを構成するという考え方はRESTの基幹をなす思想で、「接続性」とも呼ばれるRESTと分散システム
RPCは先述した通り、多くの関数を呼び出すためシステム全体の性能劣化を引き起こす。
対してRESTではリソース同士をリンクで辿ることでアプリケーションを実現する。
このリソースはRPCでやり取りするデータよりも粒度が大きいため、全体として性能劣化を抑えられる。
また、RPCでは互換性の問題もあったがRESTでは統一インターフェースが使われてるため、マイナーバージョンアップ程度では互換性の問題が発生しない。3.6 RESTの意義
RESTはWeb全体のアーキテクチャスタイルであり、RESTという理論があったからこそWebは成功している。
WebサービスがRESTfulになればWeb全体が良くなるので、Webサービスを作る際は意識するべき私見
今使われている技術の勝因、使われていない技術の敗因を知ることでどのような技術が求められるかがわかりました。
特にアーキテクチャスタイルを守ることで色々なメリットがあるので意識して設計に活かします
- 投稿日:2020-02-21T09:02:13+09:00
プログラミング学習の始め方
始めに
プログラミングを勉強して2年ぐらいたったので、
プログラミングを学ぶのによかったことを書き留める。どこから手を付ければよいか
プログラミングの知識がないと何から学習すればよいかわからないし、
調べたところで単語の意味がピンとこないと思う。
僕がおすすめするのはHTMLとJavaScriptである。(CSSは置いておく)
よく言われがちだが、僕が思う理由はいくつかある。1. 参考書が多い
始めは独学になると思うので、参考書通りに始めることで環境の設定などが流れで理解できる。
変に難しい書き方をしておらず、参考書ではコードの書き方の基礎が身につく。2. 更新した内容が目に見えてわかりやすい
やはり自分で書いたものが目に見えてわかるとテンションが上がる。
何事も楽しくないと続かない。3. お金になりやすい
人間なので、お金が絡むと学習するモチベーションが上がる。
実際にブログやLP作成で稼いでる人がいる。では、どのように学習するか。
学習のポイント
大切なのは自分で考えること
なにをするにしても誰かに言われてやることはつまらないし身につかない。
自分からワクワクするように気持ちを持っていこう。少しでも理解できてきたら
想像力を膨らます。
プログラミングを書いていてこんなことができたら楽しいなと思えるような想像をする。
想像したらなにが必要か、どうすればできそうかを考える。例えば、一覧画面を作っているならば、絞り込みを作るにはどうすればよいか。
1. 絞り込みボタンを作る
>HTMLを変更すればいいんだな。
2. ボタンが押されたら一覧に表示知するデータが変わる
>ボタンが押されたときにエベントを動かすにはどうすればよいか
3. 一覧にのデータを条件で絞り込む処理はどうするか
for分とindexOfを組み合わせればできそうこのようにしてプログラミングを楽しむことが大切
あとはTry&Errorするのみ
作っているとどうしても今の自分の知識や技術ではどうしようもないものがある。
そうしたときはとにかく調べていろいろ試してみることをおすすめする。
いろいろ試した結果できなかったら一旦諦めることも重要。
そうしていろいろ試しているうちに知識が増えていて、以前できなかったことをもう一度やってみたらできるということがある。結局のところ
大変なのは最初の数か月。
基礎が身につくと意外と難しそうでも調べればできたりする。
できることが増えると楽しい。終わりに
2年前のプログラミングを知らなかったころは業務でわからないことづくしでひーひーいっていたが、
業務外で参考書を読み漁って1年ぐらいたったころにはプログラミングの基礎と調べる力がついていた。
プログラミングを書くことはそんなに難しくないので、興味があったらぜひはじめてみてください!
- 投稿日:2020-02-21T05:04:54+09:00
初心者によるプログラミング学習ログ 245日目
100日チャレンジの245日目
twitterの100日チャレンジ#タグ、#100DaysOfCode実施中です。
すでに100日超えましたが、継続。
100日チャレンジは、ぱぺまぺの中ではプログラミングに限らず継続学習のために使っています。
245日目は、
おはようございます
— ぱぺまぺ@webエンジニアを目指したい社畜 (@yudapinokio) February 20, 2020
245日目
・youtubeで、webサイト模写
・udemyで、javascript講座#早起きチャレンジ#駆け出しエンジニアと繋がりたい#100DaysOfCode
- 投稿日:2020-02-21T00:16:29+09:00
備忘録:Javascriptでスタイルシート(CSS)を読み取ってみる。
はじめに
思いの他「知らなかった」という声をきいた内容。
Javascriptでcssの指定ができる。よく知られた内容だが、これをもっと使いやすくするコマンドがある。
getComputedStyle()
。
これは、「特定の要素から、その要素に対していま現在適用されているCSSを計算&取得する」というもの。
(現在の値を参照するので、たとえスタイルシートで指定されてない値であっても取得することができる。)Javascriptでstyle.cssの中身を読み込んで現在の状態に合わせた挙動をさせる、なんて芸当が可能になれば、ウェブデザインの幅もぐんと広がるはずだ。
getComputedStyle()
の用例
getComputedStyle()
はCSSの値全てを一気に取得する関数である。
つまり欲しいCSSを知るためには、getComputedStyle()
からさらに「getPropertyValue()
」で絞り込みをかけてやる必要があるのだ。で、以下が用例。
html<style> #prototype{ color: #f9f9f9; width: 200px; background-color: #9898fd; padding: 1em; } </style> <div id="prototype">div00</div> <script type="text/javascript"> // 要素を取得 var element01 = document.getElementById('prototype'); // element01にかかるCSSを取得 var styles = window.getComputedStyle(element01, ''); var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro); var mleft = styles.getPropertyValue('margin-left'); // margin-left console.log(mleft); </script>で、これをコンソールで見るとこうなる。
指定されていない
margin-left
であっても取得できているのがお分かりだろうか。いわゆるデフォルト値というやつだ。豆知識
色系の単位はrgb、大きさや幅、長さの単位はすべてpxに統一されている。
emやvwや%でスタイルを指定していても、返ってくるのはすべてpxなのである。また、返り値を見ればわかると思うが、返り値は数値だけでなく、その単位まで含まれた文字列で返される。
ってことは、先ほどのmargin-leftを数値として利用したいなら、javascriptvar mleft = styles.getPropertyValue('margin-left'); // margin-left var mleft_math = Number( mleft.replace(/px/g , '') ); // 数値化このようにひと手間加えてやる必要があることに注意しよう。
疑似要素での
getComputedStyle()
疑似要素にかけられたスタイルであっても取得できる。
疑似要素の場合は以下のようにしてやろう。html<style> #prototype{ color: #f9f9f9; width: 200px; background-color: #9898fd; padding: 1em; } #prototype::before{ display: block; content: 'free'; } </style> <div id="prototype">div00</div> <script type="text/javascript"> // 要素を取得 var element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = window.getComputedStyle(element01, '::before'); var beforeFS = styles.getPropertyValue('display'); console.log(beforeFS); </script>別ブラウザでの挙動
とまあこんな具合に便利さを強調してみた
getComputedStyle()
だが、欠点もある。
IEやIE、それからIEなど、このコマンドが通用しないブラウザが存在するのである。それぞれを研究したわけではないが、おおむね以下の通りの対応。。。らしい。
古めのIE(11以前)
javascriptvar element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = element01.currentStyle; var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro);ちなみに、筆者の場合以下のようにしたらIEでも動いた。
javascriptvar element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = window.getComputedStyle(element01, ''); || element01.currentStyle; var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro);おまけ:縦横の幅
CSSは
getComputedStyle()
でとれると書いたが、要素の縦幅、横幅については例外。
というのも、要素の縦幅、横幅を取得するコマンドはgetComputedStyle()
とは別に存在するのである。
.clientWidth
paddingを含む横幅
.offsetWidth
border、padding、スクロールバーを含んだ横幅
.clientHeight
paddingを含む縦幅
.offsetHeight
border、padding、スクロールバーを含む縦幅
そのへんはこちらのサイト (https://ja.javascript.info/size-and-scroll) が詳しい。
参考文献
https://amachang.hatenablog.com/entry/20070611/1181554170
https://ja.javascript.info/size-and-scroll
https://qiita.com/amamamaou/items/bb79bec002a6ff033810
- 投稿日:2020-02-21T00:16:29+09:00
Javascriptでスタイルシート(CSS)を読み取ってみる。
はじめに
思いの他「知らなかった」という声をきいた内容。
Javascriptでcssの指定ができる。よく知られた内容だが、これをもっと使いやすくするコマンドがある。
getComputedStyle()
。
これは、「特定の要素から、その要素に対していま現在適用されているCSSを計算&取得する」というもの。
(現在の値を参照するので、たとえスタイルシートで指定されてない値であっても取得することができる。)Javascriptでstyle.cssの中身を読み込んで現在の状態に合わせた挙動をさせる、なんて芸当が可能になれば、ウェブデザインの幅もぐんと広がるはずだ。
getComputedStyle()
の用例
getComputedStyle()
はCSSの値全てを一気に取得する関数である。
つまり欲しいCSSを知るためには、getComputedStyle()
からさらに「getPropertyValue()
」で絞り込みをかけてやる必要があるのだ。で、以下が用例。
html<style> #prototype{ color: #f9f9f9; width: 200px; background-color: #9898fd; padding: 1em; } </style> <div id="prototype">div00</div> <script type="text/javascript"> // 要素を取得 var element01 = document.getElementById('prototype'); // element01にかかるCSSを取得 var styles = window.getComputedStyle(element01, ''); var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro); var mleft = styles.getPropertyValue('margin-left'); // margin-left console.log(mleft); </script>で、これをコンソールで見るとこうなる。
指定されていない
margin-left
であっても取得できているのがお分かりだろうか。いわゆるデフォルト値というやつだ。豆知識
色系の単位はrgb、大きさや幅、長さの単位はすべてpxに統一されている。
emやvwや%でスタイルを指定していても、返ってくるのはすべてpxなのである。また、返り値を見ればわかると思うが、返り値は数値だけでなく、その単位まで含まれた文字列で返される。
ってことは、先ほどのmargin-leftを数値として利用したいなら、javascriptvar mleft = styles.getPropertyValue('margin-left'); // margin-left var mleft_math = Number( mleft.replace(/px/g , '') ); // 数値化このようにひと手間加えてやる必要があることに注意しよう。
疑似要素での
getComputedStyle()
疑似要素にかけられたスタイルであっても取得できる。
疑似要素の場合は以下のようにしてやろう。html<style> #prototype{ color: #f9f9f9; width: 200px; background-color: #9898fd; padding: 1em; } #prototype::before{ display: block; content: 'free'; } </style> <div id="prototype">div00</div> <script type="text/javascript"> // 要素を取得 var element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = window.getComputedStyle(element01, '::before'); var beforeFS = styles.getPropertyValue('display'); console.log(beforeFS); </script>別ブラウザでの挙動
とまあこんな具合に便利さを強調してみた
getComputedStyle()
だが、欠点もある。
IEやIE、それからIEなど、このコマンドが通用しないブラウザが存在するのである。それぞれを研究したわけではないが、おおむね以下の通りの対応。。。らしい。
古めのIE(11以前)
javascriptvar element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = element01.currentStyle; var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro);ちなみに、筆者の場合以下のようにしたらIEでも動いた。
javascriptvar element01 = document.getElementById('prototype'); // element01のbeforeにかかるCSSを取得 var styles = element01.currentStyle; var iro = styles.getPropertyValue('color'); // 文字色 console.log(iro);おまけ:縦横の幅
CSSは
getComputedStyle()
でとれると書いたが、要素の縦幅、横幅については例外。
というのも、要素の縦幅、横幅を取得するコマンドはgetComputedStyle()
とは別に存在するのである。
.clientWidth
paddingを含む横幅
.offsetWidth
border、padding、スクロールバーを含んだ横幅
.clientHeight
paddingを含む縦幅
.offsetHeight
border、padding、スクロールバーを含む縦幅
そのへんはこちらのサイト (https://ja.javascript.info/size-and-scroll) が詳しい。
参考文献
https://amachang.hatenablog.com/entry/20070611/1181554170
https://ja.javascript.info/size-and-scroll
https://qiita.com/amamamaou/items/bb79bec002a6ff033810