「Webを支える技術」を読んで 〜URI〜
こんにちは。
今日は「URI」の話。
ではガシガシ書いていきます。
URIとは
Uniform Resource Identifier
「リソースを統一的に識別するID」
これがあることによって、web上に存在するリソースを一意（それだけって意味）に示せるってわけ。
住所みたいなもんやね。
まぁ、「URL」と同じですわww
URIの構造
これも以前やりましたね。
けどもう一回おさらい。
・URIスキーム：http
上の場合は、
「httpでアクセスしますよー」
ってこと。
・ホスト名：dirty.jp
ここは必ず一意になる。
・パス：/unko/1
パスは階層を表す。
ホスト内で必ず一意になる。
URIの設計
どうやら「クールなURI」とやらがあるらしい。
URIをかっこよくしてどうすんねん。
ってことで「クールなURI」の定義は、
「変わらないURI」
どういうことかと言うと、昔のURIはコロコロ変わっていたらしい。
「お気に入り」に入れてたwebサイトがある日突然見れなくなるみたいな。
「404 Not Found」とか出たら、たしかに萎えるよね。
そこで、変わらないURIこそが最上のURIということになった。
その最上でクールなポイントがこれ。
・プログラミング言語に依存した拡張子やパスを含まない
「.rb」とか「.php」とか入れちゃダメよ。
「/cgi-bin」もダメ。CGIの時代なんかとっくに終わったんだからぁぁ。
・メソッド名やセッションIDを含めない
例えば、「showPage」というメソッド名がURIに入っていると、リファクタリングしてメソッド名が変わったときにURIも変わっちゃうから。
そしてセッションIDと言えばCookieだけど、ログイン毎にURIが変わっちゃうことはもう想像がつく。（このぼくでもww）
そんなのクールじゃないっ！！
プログラムの外部仕様（入力と出力）を変えずに、内部構造を安全に改善すること。
プログラムを理解しやすくするために、拡張性や再利用性を高めるわけやな。
要は、
「こまめに手入れしてプログラムを長持ちさせよう」
ってこと。
・URIはリソースを表現する名詞にする
ユーザが分かるように何をする場所なのかがわかりやすくしましょう、ってことやね。
ログイン画面なら、dirty.jp/login
編集画面なら、dirty.jp/edit
みたいな。
URIを変更したいとき
でも、どうしてもURI変更しなくちゃいけないときってあるよね。
システム総入れ替えとかハードウェアの老朽化とかで。
そういうときは、「リダイレクト」っていう便利な方法がある。
リダイレクトとは、古いURIを新しいURIに転送するHTTPの仕組みのこと。
今回、その方法は割愛するけど、一応そういうもんがあるって覚えておこう。
よし、今日はここまで。
ではでは、この辺で。
「Webを支える技術」を読んで 〜アーキテクチャスタイルREST〜
こんにちは。
今日から３冊目に突入です。
昨日まで読んでいた「サーバ/インフラエンジニア養成読本」ですが、文字でまとめきれなくて記事にするのを断念しましたwwww
改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)
- 作者: 養成読本編集部,200
- 出版社/メーカー: 技術評論社
- 発売日: 2016/03/18
- メディア: 大型本
- この商品を含むブログを見る
なんとなく「こんな感じ」っていうイメージはできたのでまぁいいかなww
割と用語とかコマンドの使い方が多かったので、今後もリファレンス用に使っていきやす！
そして今回からはこちら。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
１冊目に読んだ「プロになるためのWeb技術入門」をより詳しく説明したものみたい。
では、やっていきますぞい。
Webを支える技術
そもそもの話。
webを支える技術は主に３つあるんや。
HTTP, URI, HTML
URI（unform resource identifier）を使えば、世界中の情報指し示すことができる。
HTMLはそれらの情報を表現する文書のフォーマット。
そして、HTTPというプロトコル（取り決め）を使って、それらの情報を取得したり発注したりするわけ。
この３つの技術を使えばシステムが動くわけなんだけど、これを実現するには中身の設計思想が必要になった。
その設計思想の１つがREST。
アーキテクチャスタイル
「RESTとはアーキテクチャスタイルである。」
はて？
「アーキテクチャとは、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す」
うん、どうやらアーキテクチャスタイルとアーキテクチャとは別物らしい。
例をあげると、
アーキテクチャ：ブラウザ、サーバ、プロキシ、HTTP、URI、HTML
そういえば、MVC（model-view-controller）もこの１つだっけ。
つまり、システム作るときにはただ闇雲に作るのではなく、ちゃんとこういうパターンで作ってね、ってことやね。
実は「クライアント/サーバ」もアーキテクチャスタイル。
RESTはこの「クライアント/サーバ」から派生しているんやって。
んじゃRESTって何？？
REST
Representational State Transfer
先にも説明したけど、もうちょい詳しく言うと、
「RESTは複数のアーキテクチャスタイルを組み合わせて構築した複合アーキテクチャスタイル」
なるほど。
んじゃ、それぞれのアーキテクチャって何なん？？
・クライアント/サーバ
=> ユーザインタフェースと処理を分離する
・ステートレスサーバ
=> サーバ側でアプリケーション状態を持たない
「クライアント/サーバ」に最初に追加するアーキテクチャスタイル。
アプリケーション状態とはセッション状態のこと。
ログインからログアウトまでの一連の流れをセッションと呼ぶんやったね。
そうなると出てくるのが「Cookie」。
こいつはステートフルなやつ。
REST的に考えると、Cookieを使うのは間違ってるんやけど、フォーム認証行うのにCookieやめるわけにはいかないからしゃーないwww
まぁ、こういうこともあるよね。
・キャッシュ
=> クライアントとサーバの通信回数と量を減らす
一度取得したリソースをクライアント側で使い回す。
これによって、サーバとクライアント間での通信回数が減らすことができるんや。
けど、古いキャッシュを使っていると情報の信憑性が下がるから要注意。
・統一インターフェース
=> インターフェースを固定する
URIで指定したリソースに対する操作を、統一した限定的なインターフェースでやりましょう、ってこと。
・階層化システム
=> システム階層に分離する
サーバ/クライアント間には、ロードバランサを設置して負荷分散したり、プロキシを設置してアクセス制限したりする。
・コードオンデマンド
=> プログラムをクライアントにダウンロードして実行する
プログラムをサーバからダウンロードし、クライアント側でそれ実行する。
JSとかFlashがそう。
これら６つのアーキテクチャスタイルを組み合わせたのがRESTってわけやな。
細かいとこは実際に触りながら覚えていくとしよう。
では、今日はここまで。
「サーバ/インフラエンジニア養成読本」を読んで 〜SSHでCentOSにログイン〜
こんばんは。
今回は、よく使われる「SSHでログイン」について。
........？？（はい出たー、ナニソレ的なやつー）
まずは前回したサーバOSの話をちょこっと。
実は、サーバOSは直接サーバ本体を操作しなくてもイジイジできちゃうらしい。
１台のPCに仮想環境を用意して、その上でサーバOSを動かすんや。
.......？？（仮想環境ってなんや）
超簡単に言うと、１台のPCにもう１台PC作っちゃおう的な。
このもう１台のPCが仮想環境で、使うには仮想化ソフトウェアを導入する必要があるみたい。
無償だし情報もいっぱいあるしね。
話を戻すと、このVirtualBoxにCentOSを入れたらもう１台のPC完成ってわけ。
よし、SSHでログインしてみよう！
secure shell
SSHとは暗号化された通信で、ネットワークを介してリモートアクセスするのに使うんやって。
暗号化されてるから安全な通信が可能らしい。頼もしいね。
この設定の話はちょっと今回割愛でwww
サーバがあるってことはクライアントよねー。
ってことでSSHクライアントが必要になるわけやね。
代表的なのがこれら。
・Tera Termttssh2.osdn.jp
http://www.chiark.greenend.org.uk/~sgtatham/putty/
・Macターミナル
これらはターミナルエミュレーターって言うらしい。
ちなみに、
ぼくはこのターミナルエミュレーターって言葉知らなくて、
「このコマンドどこで打ちゃいいんだぁぁぁぁぁっぁぁっぁ」
ってなったことがありますwwww
まぁまぁそこは置いといて。
実際にTera Termを使う場合どうやるか？
Tera Termでサーバにアクセスするには、
サーバのホスト名やIPアドレスが必要になる。
.......ごめん。
もう気付いてるかもしれないけど、文字だけじゃ説明しにくいwwwwwww
ってことで最後にもう１回「SSHでログイン」のおさらい。
ぼく（クライアント）：「マササーバにログインしまーす！！」
マサ（サーバ）：「ホストの指定は.....うん、合ってるね。パスワードもOK! ようこそ
マサワールドへ！！」
こんな感じwwwww
では、今日はこの辺で。
「サーバ/インフラエンジニア養成読本」を読んで 〜新人エンジニアのための基礎講座〜
こんばんは。
昨日まで就活で東京に来ておりました。
突然ですが、ぼくの就活スタイルはズバリ、
「スーツ絶対着ない！」www
もちろん、今回行ってきた４社とも私服で参加しました。
この私服only主義がモロに出たのが、１社目。
私服参加OKのとこだったので問題はありませんが、見事にぼくだけ私服。
ちょー気まずかったwww
しかし、ここで怖気付かない。
堂々と一番前の席に座ってやりましたよww
１次選考も無事に通過したので結果オーライです。
さて、今日からこのブログでまとめる本は、
「サーバ/インフラエンジニア養成読本」。
改訂3版 サーバ/インフラエンジニア養成読本 (Software Design plus)
- 作者: 養成読本編集部,200
- 出版社/メーカー: 技術評論社
- 発売日: 2016/03/18
- メディア: 大型本
- この商品を含むブログを見る
ちょっと難しそう。
でも頑張るよし！！
みなさんの初めてのPCは何でしたか？？
ちなみにぼくはMicrosoftのSurface Pro2でした。
Windows OSの一番の特徴は、
GUIが整備されている
ということ。
GUIとは、Graphical User Interface。
簡単に言うと、マウス操作を基本としたグラフィカルな画面でわかりやすく情報のやりとりができる。
また、エディタで設定ファイルを書く必要がないから、設定に自信がない人には使いやすらしい。
けど、複数のサーバにちょこっと（または同じ）設定をする場合は、サーバごとにラインセンス費用がかかってしまうのがちょっとめんどいところ。
そもそも「Linux」って言葉、聞き慣れないよね。
そもそものそもそも、よく耳にする「windows」とか「mac」ってのはOSのことを言ってるんやね。
「windowsが入ってるPC」って言うでしょ？
このLinuxも同じOSのことなんだけど、無料なのだ。（商用の場合はライセンス費用がかかる）
ちなみに、
無料Linux
・Cent OS
など
有料Linux
・SUSE
など
話を戻すと、Linuxの一番の特徴は、
CUIが整備されている
ということ。
CUIとは、Character User Interface。
テキストベースで基本操作するので、自動化が簡単で、大量のサーバを管理する場合は圧倒的にLinuxの方が楽らしい。
黒画面に緑文字で、英語がガァーっと並んでるのイメージすると分かりやすいかな。
また、GUIがない分メモリを無駄に消費せず、高速な処理と、サーバの性能を最大限に使い切ることが実現できるんやって。
これはOSとアプリケーション実行環境の間に入って、動作を仲立ちしてくれるソフトウェアのこと。
実はここ、過去記事で書いたおかみさんとか職人さんのことを言うんよね。
その記事がこれ↓
簡単にミドルウェア名を紹介しておくと、
・Webサーバ（おかみさん）
・Appサーバ（職人さん）
→ Tomcat , JBoss , Unicorn , Gunicorn
・DBサーバ（素材屋さん）
→ Oracle , PostgreSQL , MySQL , SQLserver , DB2
これら３つまとめてミドルウェア。
今後超使うからこの言葉は覚えておこう。
キリがいいので今回はここまで。
次回は「仮想環境・Cent OS」からやっていきます。
そもそもなんでお前ISUCON出んの？
こんばんは。
本日２度目の投稿ですww
１冊目終わりちょうどキリがいいので、ここらでISUCON出場のきっかけや関係者について書いていこうかなと。
ISUCON出場のきっかけ
ちょうど２週間前。
とあるプロジェクトで一緒に開発していて、色々教えてくれる先輩エンジニアのさぼさんって方がいてですね。
さぼさん：「ISUCON出たら就職できるよ？ww」
ぼく：「は、はい......。（イスコンってなんだ？むしろ美味そうじゃないか！！）」
こうなったわけですよww
ちょうどその頃のぼくはと言うと、就活真っ最中で、渋谷ヒカリエにオフィスがある会社に落ちたとこだったんですねー。
就活振り出しになったぼくは、会社選びについてさぼさんに相談していたところ、さっきの会話になったというわけですw
そもそもですが。
ISUCONってのは競技プログラミングの大会で、毎年９月にLINE本社で行われます。
予選・本戦があって、本戦に勝ち進んでくる人たちはいわゆる「ハイパーなエンジニア」と呼ばれる方たちです。
しかしこの人たちは「一般枠」。
実は「学生枠」ってのもあるんですね。
どうやらさぼさんがおっしゃるには、予選までの半年間、基礎からみっちり勉強すればこの「学生枠」での本戦出場は可能であると。
しかもさぼさん自らがコーチングしてくれると。
ぼく：「はい、やります！」
ちょー単純wwwwww
こうしてさぼさんをコーチにお迎えして、ぼくのISUCON出場向けての成長物語が始まったわけです。
ぼくと心中してくれる２人の仲間
こうしてISUCONを目指すことが決まったわけですが、早速問題が。
１人では出場できないのですwww
ってことで仲間集めから。
このときぼくの頭にはとある１人が浮かび上がりました。
ちょくちょくこのブログでも登場する「マサ」ですwwwwwwww
間髪入れずにマサに連絡。
このあとめっちゃ煽りましたw
多分彼は今まででとてつもない煽りを受けたことでしょうwww
（ごめんねマサw）
そんなこんなして
マサ、鼻血プシャーー！！！
ぼくはその時思いましたね。
「一人目確保」。
その後日、マサはさぼさんと会って色々説明を受けて、正式に仲間になりましたwwww
問題はあと１人。
結構デキる学生エンジニアを口説きにいきますが、ぼくらの実力を値踏みしてか、口説き失敗に終わりました.......。
まずい。あと１人......。
とりあえず２人でスタートし、ISUCON出場への第一課題。
さぼさん：「よし、まずはMac買おう。」
ぼく・マサ：「了解です！」
こうして８ギガのi7Macを買って第一課題クリアwwww
そうこうしてるうちにコンサル会社のインターンシップが。
そこである一人の男と出会う。
Youtuberのマギー
一時期Youtubeで稼いでたらしいww
そんなマギーとぼくはインターンで一緒のグループになり、突然
マギー：「プログラミング好きなんです。学部も情報工に変えました。」
ぼく：「お、おう.....。（なんやこいつ。告白する相手間違っとるやろ。）」
あんまりに突然だったのでぼくは思考停止状態。
そして我に返った時、ピンときた。
ぼく；「（こいつも道連れや）」
マギーにISUCONのこと話すが、彼は自信なさげww
どうにかこうにか口説く（煽るww）が、最後の「Yes」が出てこない。
ここで最終手段。
ぼく：「とりあえずさぼさんに会ってみたら？」
すると
マギー：「じゃあ、やります！」
こうしてぼくと心中してくれる２人目の仲間が加わったのですwww
フリーランス学生のぼく、セブんちゅのマサ、そしてYoutuberのマギー。
先輩エンジニアのさぼさんの指導の下、精一杯やっていきますのでどうか温かく見守っていただけるとありがたいです。
人物紹介
・さぼさん
・マサ
・マギー
「プロになるためのWeb技術入門」を読んで 〜Webシステムの三層構成〜
こんにちは。
「プロになるためのWeb技術入門」シリーズ、今回が最後です。
テーマは「Webシステムの三層構成」。
・Webサーバ
・・・女将さん
・Appサーバ
・・・職人さん
・DBサーバ
・・・素材屋さん
こいつらが互いにあんなことやそんなことやこんなことまでしてるんやって。
んで、この３つはシステム開発する上で必ず登場するみたい。
ソフトウェア構成の基本の基本の基本のそのまた基本。
絶対押さえとかなきゃいけないね。
よし、やろう！
と、サーバの話の前に「ノード」について。
ノード
一つのシステムを動かすために、Webサーバ・クラインアントみたいに複数のコンピュータがあった。
この時、各コンピュータのことを「ノード」って呼ぶらしい。
コンピュータの他に、ハブとかルータもそう。
まぁここはさらっと。
では「三層構造」。
それぞれを擬人化して説明していく。
・Webサーバ
まずは女将さんこと「Webサーバ」。
なぜ女将さんかと言うと、こいつが司令塔だから。
クライアントからのリクエストをまず女将さん（Webサーバ）が受け取る。
この女将さんが的確に指示出してあげないと、後に続く職人さん（Appサーバ）や素材屋さん（DBサーバ）が仕事できないってわけ。
どうやらこいつは最強にしないといけなさそうだ。
ちなみに「nginx」（nginx - Wikipedia）使う予定。
・Appサーバ
こいつは職人さん。
女将さん（Webサーバ）から指示を受けてせっせと働くんやな。がんばれ。
こいつの役割は、
・セッション管理
・・・セッションIDの発行や管理
・トランザクション管理
・・・業務上、まとめて確実に実行される一連の処理（トランザクション）
ん、なんやそれ....?
例えば、ネットで買い物したときのトランザクションは
・商品在庫を一つ減らす
・クレジットカードの請求処理を行う
みたいな。
・DB接続の管理
・・・DB接続 / 切断
DBはドラゴンボールやないで。
データベースや。
情報が表にまとまってるイメージかな。
職人さんだからもっとやることはいっぱいあるけど代表的なやつをちょこっと紹介。
うん、どうやらこいつも最強に育てなければならないらしい。
Ruby使うならUnicorn + Sinatra (またはRuby on Rails)かな。
・DBサーバ
今回初登場の素材屋さんこと「DBサーバ」。
大量の情報を管理してくれる。
「CRUD」っていうDBに対する基本操作があって、下の４つがそれ。
・生成（Create）
・・・新しい情報をDBに登録する
・読み取り（Read）
・・・DBに登録されている情報を読み取る。条件によって合致する情報を抽出する（これが検索処理）
・更新（Update）
・・・DBに登録されている情報を更新する。
・削除（Delete）
・・・Dbに登録されている情報を削除する。
例えば、マサ（以前登場した人物。別の記事でちゃんと紹介しますww）のプロフィールをDBに登録する。
まず、「マサのプロフ」っていう表を用意する。
これが「テーブル」。
んで、名前とか誕生日とか身長とか体重とかの各項目があるでしょ。
これが「カラム」。
これだとマサの情報だけで一行になっちゃうからアレなんだけどね。
これが「AKB48のメンバー」になると、何行にもなるよね。
この時、一行のまとまった情報に対して「レコード」って言うんや。
そしてSQLっていうDB専用言語を使って、必要な情報を取り出すってわけ。
SQLの命令は、
・何を
・・・マサの「誕生日」を
・どこから
・・・「マサのプロフ」テーブルと「AKB48のメンバー」テーブルから
・どのように
・・・誕生日が同じ、という条件で
取り出す。
ざっとこんな感じ。
これらをAppサーバとDBサーバがSQLを使って情報の受け渡しをしているんや。
情報が多くなってくるとこいつも最強にしなければならんな。
ちなみに使うとするなら「MySQL」とか「PostgreSQL」かな。
実際にISUCONで戦うとなると、CPUとメモリから判断してこの３つの内、どいつを最強（チューニング）にしていくかってことになる。
各サーバを１つのノードにまとめて入れるのか、それとも１ノード１サーバにするのか。
それぞれにMAXパフォーマンスを出させてあげて、それでも重くなるようだったらサーバ（ノード）分けてあげるとか。
まぁ色々パターンはあるみたい。
一般的な構成としては、WebサーバとAppサーバとDBサーバを１つのサーバ（ノード）にまとめて入れちゃうみたい。
ちなみに「オートスケール」っていう、自動でサーバを増やしたり減らしたりすることもできるみたい。
「あ、こいつやばいな。サーバ増やして負荷軽くしてやろう」
みたいな。
以上が「Webシステムの三層構成」。
女将さん・職人さん・素材屋さんのどれから最強（チューニング）にしていくのか、作戦会議をしながら進めるみたいです。
「プロになるためのWeb技術入門」終わり！！
（ISUCON出場に向けて、本書の全７章のうち５章までを読みました。）
「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか
- 作者: 小森裕介
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/10
- メディア: 大型本
- 購入: 57人 クリック: 1,242回
- この商品を含むブログ (35件) を見る
「プロになるためのWeb技術入門」を読んで 〜Cookie〜
今日は「Cookie」について。
なんだか美味しそうだね。
ちなみにぼくはオートミールクッキーが好きですw
Cookieとは
Webブラウザに情報を持たせる技術。
WebアプリケーションとWebブラウザ間で情報を交換できる技術。
どーゆーことかと言うと、
ログイン情報とかの来訪履歴って感じかな。
ブラウザ：「こんちはー。」
サーバ：「いらっしゃいませー。お、初来店やね。じゃあ会員証（Cookie）やるよ。」
ブラウザ：「あざっす！」
ブラウザ：「やぁ、またきたでー。」
サーバ：「会員証（Cookie）確認おっけー。」
ブラウザ：「お、この前買い悩んでたものまだカゴに残ってるやんけ。」
サーバ：「せやで。おれってええ奴やろ。」
ブラウザ：「あざっす！」
Cookieはサーバからブラウザに送られる。
各アクションごとに情報が更新されてく。
例えば、
・ログイン時のユーザ情報登録で更新
・何か買ったら更新
みたいな。
こうやって毎回同じサイトにきた時にいちいちログイン情報を入力しなくていいわけやな。
うん、便利や〜。
でも、そんな美味しくて便利なCookieにも問題点があるんやと。
どうやらCookieはテキストファイルとしてPC上に保存されるらしい。
ダイアログをのぞけばそれが見れるんだって。
困ったな、どうしようか。
セッションID
銀行窓口の受付番号的なやつ。
「受付番号372番でお待ちのお客様、お手続きが完了いたしましたので窓口までお越しくださいませ。」
そう、これこれ。
こうすれば個人名呼ばれなくて済むよね。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
セッションID：372
名前：マサ
受付：完了
手続き：手続き中
完了：まだ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
このセッションIDをCookieに入れてサーバとクライアントがやりとりをするんやな。
結局のところ、Cookieを使うことに変わりはないからCookieの情報を分からなくしてやろうって考え方やね。
もちろんセッションIDはただの数字（または文字列）だから誰が見ても分からんというわけ。
イメージとしては、DBから取ってきた情報を変数に入れるイメージかな？
ここらへんはもうちょっと調べてみよう。
ではでは、今日はこの辺で。
