『Webを支える技術』第4部
第4部は、ハイパーメディアフォーマットというタイトルです。 内容は以下のような感じです。
- HTML
- microformats
- Atom
- AtomPub
- JSON
今回は、「どういう形式でデータをやり取りするか」という内容が比較的多く、記法についての説明も結構ありました。 でも、記法に関しては自分で書かないと忘れちゃうので、その辺に関しては軽くまとめつつざっと流し読みしました。
microformatsとAtomに関しては、今回初めて知ったので、少しだけ概要をまとめておきたいと思います。
(Atomって聞いて、真っ先にエディタが出てくるのはしょうがないよね...)
microformats
microformatsは、軽量にセマンティックWebを実現できるフォーマットらしいです。
雑な説明になりますが、セマンティックWebはHTMLやXMLで書かれたリソースがプログラム的にどういう意味を持っているかということです。
microformatsは、そのセマンティック情報をHTML上のリソースに埋め込むことで目的を達成するようです。
これを見た時、「これ普及したら、スクレイピング捗るしすごそう！」って思ったんですけど、 よくよく考えたら普通にWebAPIでJSON返す形式にした方がネットワークリソースの節約(Webページが軽量になる)し、 いざ利用しようとした時わざわざ自分でスクレイピングスクリプト書かなきゃいけなさそう(?)なので、APIの方がいいのでは？ってなっています。
WebAPIを提供するってなった時、開発側はAPIのメンテナンスをする必要があるけど、 自分がmicroformatsやAPIを利用する側になった時の事を考えると、 「いつ構造が変わってもおかしくないmicroformatsより、シンプルでドキュメントも整っているAPIの方が絶対使いたい」 って思うような気がしました。
Atom
これも初めて知りました。 正式名称はAtom Syndication Formatっていうみたいです。
元々は、RSSの仕様が乱立していた時に、その標準化を目的の1つに掲げて策定され、フォーマットはXMLベース。 それぞれのリソースに対して、タイトル、著者、更新日時は必須で、メタデータとして付与されていて、ブログサービスAPIとかに使われているみたいです。
拡張性も良い点みたいで、色々な所に使われているみたいなのですが、正直どれくらい良いものなのかは実際に使ってみないと分からなさそうです。。。
明日は第5部、Webサービスの設計の話です。(一番楽しみなやつ)
おやすみなさい。
『Webを支える技術』第3部を読んで
今日は『Webを支える技術』第3部、HTTPについての話題でした。
HTTPの仕様は、RFC2616にまとめられていて、現在のバージョンはHTTP1.1です。
本の内容としては、HTTPメッセージの大枠から入り、HTTPメソッド、ステータスコード、HTTPヘッダ、 HTTP1.1ならではの機能(チャンク転送、コンテントネゴシエーション等)の説明...という流れ。
ここでは自分が特に印象に残ったことだけ書きます。
HTMLで使えるHTTPメソッド
HTMLのformタグでデータを送信したりできると思いますが、そこで使えるHTTPメソッドはGETとPOSTしかありません。
PUTやDELETEメソッドを送る時は、_methodをhiddenで指定したり、Ajaxで行なったりするみたいです。
でも、そもそも「PUTやDELETEもよく使うのに、なんでサポートしてないの？追加すればいいのに。」って思いました。
これについては、同じことを思った人がいたみたいで、調べたらこんな記事がありました。
詳しくはリンクを見て欲しいのですが、議論はあったみたいなのですが、現状は必要無いと判断されているみたいです。 (あれば便利くらいで気軽に仕様を追加するべきではないっていう見解みたいです。)
それよりも、formタグからHTTPヘッダを追加できない事の方が問題らしく、 メソッドを指定するだけじゃなく、HTTPヘッダも追加したりできるように拡張される動きがあるみたいです。
もし、ドラフトが通れば、HTML5.1でformタグからPUTやDELETEも指定できるようになると思います。
認証
本では、認証のアルゴリズムとして3つ紹介されていました。
- Basic認証
- Digest認証
- WSSE認証
Basic認証は "{ユーザ名}:{パスワード}"をBase64エンコードして送信して認証するが、Base64は簡単にデコードできるので、 実質パスワードを平文で流しているのと変わりません。
Digest認証は ユーザ名、パスワード、ノンス等をMD5ハッシュを複数回適用することで、復号できないダイジェストを生成して認証する。 Digest認証を用いる場合、サーバ側でユーザ名とパスワードに関してあらかじめMD5ハッシュ化したものを保存すればよい。 (つまり、サーバ側でもパスワードを生で保存しなくても良くなって、セキュリティレベルが向上する。)
WSSE認証は パスワード、ノンス、生成日時をSHA-1ハッシュして認証する。 このアルゴリズムを使う場合、サーバ側では生パスワードを保存しておく必要があるみたいですが、 Digest認証よりも簡潔なのが売りみたいです。
セキュアレベルは、Digest認証 > WSSE認証 > Basic認証で、手軽さはその逆。
特に、Basic認証をする時は、ネットワーク上にパスワードを生で流すことになるので、HTTPS接続して暗号化しないとダメなので注意ですね。
アルゴリズム的には、Digest認証がすごく面白いなーって感じました。 以下のサイトを見ると、どういう仕組みで脆弱性対策をしているのか分かりました。
でも、最近はHTTPS化の流れが来ていますし、そうなるとわざわざDigest認証を使わなくても、Base認証で事足りちゃうんですかね？
その他
後は、たとえキャッシュの有効期限が切れてもIf-None-Match+ETagで、最低限の通信でリソースの鮮度を保証する仕組みとか、 チャンク転送によるパフォーマンス改善の話とか個人的に面白かったです。
明日は第4部読みます。おやすみなさい。
『Webを支える技術』第2部
昨日に引き続き、今日は『Webを支える技術』の第2部を読みました。
第2部は、主にURIの話でした。
URIの仕様
個人的に引っかかったのは、「URIの長さの最大が2,038バイト」ということです。 IEでのURIの指定が最大2,038バイトだから、事実上それ以上の長さのURIは止めましょうってなってるらしいです。 それにしても、中途半端な数値ですねー？
URIスキーム
あとは、URIのスキーム(httpとか、httpsとかのアレ)も、自分が思っていたよりも沢山の種類があるらしいです。 IANAという所が、ココに公式スキームの一覧が載ってます。
2018年4月13日現在だと、Permanentステータスのやつが94個ありました。 とりあえず、ftpとかsshとかwsとか自分の知ってるやつを見つけて喜んで、後は流し見してそっ閉じ。
クール👍なURI
そんで、今日読んだ所で一番テンション上がったのは、「クールなURI」の話です。 良いURIとは、綺麗かつ不変的で、それを揺るがす設計はダメだよっていう話でした。 (URIが変わると、ハイパーメディアが機能しなくなる！)
今まで、Railsとか触った時とかに、「URIはこういう風に組みましょう！」みたいな例が確かあって、それで何となく分かった気でいたんですけど、 こういうちゃんとした背景があったんだなと、ハッとしました。
あと、なんか自分はシンプルな設計に妙に惹かれている部分がある。 昨日のRESTの話といい、めっちゃ好き。
今日は色々と忙しくてあんまり読み進められなかったような気もするんですけど、明日は第3部読んでいきたいと思います。
『Webを支える技術』読み始めた
Web技術の基礎をちゃんと固める意味で、『Webを支える技術』という本をオススメされました。
という訳で、今日は早速その第1部だけ読みました。 (めっちゃ面白いです。)
第1部はWeb概論ということで、Webの歴史とRESTについてのお話が中心でした。
読み進めていく中で、色々な人が登場してくるのですが、自分が「あ、こいつヤバイな」って思ったのはBerners-LeeさんとRoy-Fieldingさんいう人です。
Berners-Leeさんは、1990年11月中旬にWebの提案書を書いて、クリスマス頃に最初のバージョンのブラウザ+サーバを完成させたらしいです。 (つまり、提案してから1ヶ月半...) 最初のバージョンは今と比べて高機能ではなかったと思いますが、新しいものを構想して実現するまでのスピードの速さに感動しました👍
Roy-Fieldingさんは、大学院生時代にWebをアーキテクチャの観点から分析して、アーキテクチャスタイル(これが後のREST)を提案したり、 Berners-Leeさん達と一緒にHTTPの標準化に貢献したりした人です。 自分と年はそう変わらないのに、、、すごい人です。
あと、面白かったのはSOAP vs RESTのプロトコル戦争の所です。(結果は、RESTが勝って今に至るみたいです。) SOAPよりもRESTの方がシンプルで手軽らしいので、僕個人としてはRESTが勝って嬉しいです。(単純)
RESTの定義も、今まで漠然と「GETメソッドとか、POSTメソッドとか、DELETEメソッドのアレでしょ」みたいに考えていたんですけど、 厳密にはクライアント/サーバのスタイルにいくつかの制約を足したものらしく、HTTPメソッドの話はその一部みたいですね...。(恥ずかしいです)
明日は第2部読みます。
1ヶ月の振り返り
こんばんは、日に日に近所の桜が散ってきていますね。
私、満開の桜を見るのも好きなんですが、この散っていく桜を見るのも好きなんですよね。
言葉にするのが難しいんですけど、散っていく桜はまさに盛者必衰という言葉がぴったりで、その儚さと繊細さに"美しい"って感じます。
あと、桜じゃなくても、何かモノが壊れる瞬間に芸術を感じますね。 でも、生き物が衰弱していく様は、芸術云々の前に"可哀想"が先行するんですけどね...。(サイコパスじゃないよ！)
...っと、こんなこと書く記事じゃ無かった😅
さて、実はこのブログも始めてもうすぐ1ヶ月になります。(最近書けてなかったんですけどね)
なので、ここいらで1ヶ月を振り返りを軽くまとめておこうと思います。
オセロAI
この1ヶ月で一番力を入れたのは、オセロAIの開発でしょうか。
手法とかも大方確立されてきているとはいえ、その中でも採用する手法に選択の余地はありますし、 アルゴリズム的にも決して簡単というわけではないと思うので、やりがいもあって楽しかったです。
実装としては、
- 盤面のビットボード実装(置き場所の列挙、反転処理等をビット演算で行う)
- 中盤探索(NegaMax法)
- 終盤探索(NegaScout法、終盤1手最適化、終盤n手全探索、空所表、ハッシュによる置換表)
辺りでしょうか。 特に、終盤に関しては最初NegaMax法による探索のみで動かしていた時と比べて、約1,800倍くらいになりました。
まだまだ改良したい点はあるんですけど、優先順位的に一旦AI作成は中断して、アプリ側の方に取り掛かっています。
Nim言語
今回、オセロAIを作るに当たってNim言語を採用しています。
Nimは「効率的で表現豊かで優雅」に設計されていて、マルチパラダイムだけどメタプログラミングの要素が強いみたいです。(メタプログラミング使えない顔)
自分が良いと思った点は、
辺りですね。書いていて楽しい言語です。
ただ、あまりにもマイナー言語過ぎて、日・英共に記事が参考記事が少な過ぎるのが難点で、 実際Nim言語のクロスコンパイルがずっと分からなくて辛いです、他言語に移植するまで考えているレベルです😢
まぁ、辛いことはありますけど、こういう未知の領域に足を踏み入れるのは、なんか時代の先端にいる感じがして楽しいですし、 Nimが発展してもしなくても、その理由を探ることでこれから時代の流れを読むための学びが得られるんじゃないかなと期待しています。
Nimはいいぞ。
その他
その他やったことは、
とかです。
反省点
「Nimのクロスコンパイルをするために時間がかなり取られて、結局できていない」、これに尽きるかなぁと思います。
粘り強く、辛抱強く取り組むのは、それはそれで大事だと思っていますけど、それだけじゃダメだなって強く感じました。
自分にとって未知の領域に踏み込む時、限られた時間の中で成果をあげるために、ある程度テクニカルリスクを考慮して 実現できるか事前検証したり、 代替案を用意しておいたり、 代替案に切り替える期限を設けたり する事も大事なんじゃないかなと思いました。(周囲に聞ける人がいない環境では特に！)
この1ヶ月は、その辺が甘かったと思いました。
これから1ヶ月やりたいこと
この1ヶ月で、オセロのコアロジック部分の実装はざっくり終わりました。(クロスコンパイルだけが鬼門)
前節で述べた通り、Nimのクロスコンパイルができていなくて、多分このまま闇雲にやり続けていても厳しいと判断したので、 Rustに移植しそれを組み込む方針で考えたいと思います。(Rustのクロスコンパイルについては検証済み)
最初は、この1ヶ月で通信関連を先にやろうと思ったんですけど、よく考えたら端末側のオセロのコアロジックを組むのが先だと感じた軌道修正してました。
なので、次の1ヶ月はサーバを立てて、端末と端末の間で情報のやり取りが行えるようにしたいと思います。 そして、もし余裕があればフロント側の機能も整えていこうと思います。
サーバ側の技術は、AWS+Docker+Scala+PlayFrameworkでやってみたいと思います。
お、なんか書いていたらテンション上がってきた。がんばろ〜😆
久し振りの投稿
こんばんは、久し振り(3日振り)の投稿になります。
理由なんですけど、学校やら何やら色々始まって考えることが増えてあたふたしてたこと、 花粉か睡眠・食事の乱れか分からないんですけど(頭の)体調が優れなかったこと、 自作アプリの方も技術的に自分の分からない所が出てきて詰まっていたこと等辺りです。
分からない点が出てくるのはまぁしょうがないんですけど、1番目と2番目は流石にマズイので、自分なりに対策を打っていきたいと思います。
月単位・週単位の目標を立てる
私は自分の予定はGoogleカレンダーに記録して管理してるのですが、その他の自分のタスク(何を、どこまで、いつまでにやる)については頭の中で何となく管理していました。
何となく管理しているので、自分が今やっている事は順調なのか、遅れているのかがあやふやになり、 自分の中にナゾの余裕が生まれてしまっているような気がしました。
なので、これまで頭の中で考えていたタスクを月単位、週単位、(必要なら日単位)で明確化することにしました。 目標を明確にすることで、プロジェクトの進行度合いを評価できて、結果的に最初予定していた地点に着地できる可能性が高いと思いました。
とりあえず、やってみよう。
健康に気を使おう
久しぶりに3日連続で3, 4時寝とかして調子が悪くなって、「あぁ、僕はもうおじいちゃんなんだ」と改めて実感しました。
生活水準のボトルネックは大体、睡眠、食事、運動だと思うので、気をつけていきたい。
とりあえず、夜11時くらいに電子類は切る運動を始めようと思う。
