読者です 読者をやめる 読者になる 読者になる

おれ、エンジニアになるよ。

エンジニア志望の大学生がISUCON7出場を目指す成長日記

そもそもなんでお前ISUCON出んの?

こんばんは。

本日2度目の投稿ですww

 

1冊目終わりちょうどキリがいいので、ここらでISUCON出場のきっかけや関係者について書いていこうかなと。

 

 

ISUCON出場のきっかけ

 

ちょうど2週間前。

とあるプロジェクトで一緒に開発していて、色々教えてくれる先輩エンジニアのさぼさんって方がいてですね。

 

さぼさん:「ISUCON出たら就職できるよ?ww」

ぼく:「は、はい......。(イスコンってなんだ?むしろ美味そうじゃないか!!)」

 

こうなったわけですよww

ちょうどその頃のぼくはと言うと、就活真っ最中で、渋谷ヒカリエにオフィスがある会社に落ちたとこだったんですねー。

就活振り出しになったぼくは、会社選びについてさぼさんに相談していたところ、さっきの会話になったというわけですw

 

そもそもですが。

ISUCONってのは競技プログラミングの大会で、毎年9月にLINE本社で行われます。

予選・本戦があって、本戦に勝ち進んでくる人たちはいわゆる「ハイパーなエンジニア」と呼ばれる方たちです。

しかしこの人たちは「一般枠」。

実は「学生枠」ってのもあるんですね。

 

どうやらさぼさんがおっしゃるには、予選までの半年間、基礎からみっちり勉強すればこの「学生枠」での本戦出場は可能であると。

しかもさぼさん自らがコーチングしてくれると。

 

ぼく:「はい、やります!」

 

ちょー単純wwwwww

 

こうしてさぼさんをコーチにお迎えして、ぼくのISUCON出場向けての成長物語が始まったわけです。

 

 

 

ぼくと心中してくれる2人の仲間

 

こうしてISUCONを目指すことが決まったわけですが、早速問題が。

1人では出場できないのですwww

 

ってことで仲間集めから。

このときぼくの頭にはとある1人が浮かび上がりました。

 

ちょくちょくこのブログでも登場する「マサ」ですwwwwwwww

 

間髪入れずにマサに連絡。

 

f:id:matsuda-juri:20170417190536p:plain

 

このあとめっちゃ煽りましたw

多分彼は今まででとてつもない煽りを受けたことでしょうwww

(ごめんねマサw)

そんなこんなして

 

f:id:matsuda-juri:20170417190804p:plain

 

 

マサ、鼻血プシャーー!!!

 

ぼくはその時思いましたね。

「一人目確保」。

 

その後日、マサさぼさんと会って色々説明を受けて、正式に仲間になりましたwwww

 

 

問題はあと1人。

結構デキる学生エンジニアを口説きにいきますが、ぼくらの実力を値踏みしてか、口説き失敗に終わりました.......。

 

まずい。あと1人......。

 

とりあえず2人でスタートし、ISUCON出場への第一課題。

 

さぼさん:「よし、まずはMac買おう。」

ぼくマサ:「了解です!」

 

こうして8ギガのi7Macを買って第一課題クリアwwww

 

そうこうしてるうちにコンサル会社のインターンシップが。

そこである一人の男と出会う。

 

Youtuberのマギー

 

一時期Youtubeで稼いでたらしいww

 

そんなマギーとぼくはインターンで一緒のグループになり、突然

 

マギー:「プログラミング好きなんです。学部も情報工に変えました。」

ぼく:「お、おう.....。(なんやこいつ。告白する相手間違っとるやろ。)」

 

あんまりに突然だったのでぼくは思考停止状態。

そして我に返った時、ピンときた。

 

ぼく;「(こいつも道連れや)」

 

マギーにISUCONのこと話すが、彼は自信なさげww

どうにかこうにか口説く(煽るww)が、最後の「Yes」が出てこない。

ここで最終手段。

 

ぼく:「とりあえずさぼさんに会ってみたら?」

 

すると

 

マギー:「じゃあ、やります!」

 

こうしてぼくと心中してくれる2人目の仲間が加わったのですwww

 

 

フリーランス学生のぼく、セブんちゅのマサ、そしてYoutuberのマギー

先輩エンジニアのさぼさんの指導の下、精一杯やっていきますのでどうか温かく見守っていただけるとありがたいです。

 

 

 

人物紹介

 

・さぼさん

saboyutaka.hatenablog.com

 

 

 ・マサ

masa-world.hateblo.jp

 

 

・マギー

twitter.com

 

「プロになるためのWeb技術入門」を読んで 〜Webシステムの三層構成〜

こんにちは。

「プロになるためのWeb技術入門」シリーズ、今回が最後です。

 

テーマは「Webシステムの三層構成」。

・Webサーバ

・・・女将さん

 

・Appサーバ

・・・職人さん

 

・DBサーバ

・・・素材屋さん

 

こいつらが互いにあんなことやそんなことやこんなことまでしてるんやって。

んで、この3つはシステム開発する上で必ず登場するみたい。

ソフトウェア構成の基本の基本の基本のそのまた基本。

絶対押さえとかなきゃいけないね。

よし、やろう!

 

 

と、サーバの話の前に「ノード」について。

 

 

ノード

 

一つのシステムを動かすために、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に対する基本操作があって、下の4つがそれ。

 

・生成(Create)

・・・新しい情報をDBに登録する

 

・読み取り(Read)

・・・DBに登録されている情報を読み取る。条件によって合致する情報を抽出する(これが検索処理)

 

・更新(Update)

・・・DBに登録されている情報を更新する。

 

・削除(Delete)

・・・Dbに登録されている情報を削除する。

 

例えば、マサ(以前登場した人物。別の記事でちゃんと紹介しますww)のプロフィールをDBに登録する。

まず、「マサのプロフ」っていう表を用意する。

これが「テーブル」。

 

んで、名前とか誕生日とか身長とか体重とかの各項目があるでしょ。

これが「カラム」。

 

これだとマサの情報だけで一行になっちゃうからアレなんだけどね。

これが「AKB48のメンバー」になると、何行にもなるよね。

この時、一行のまとまった情報に対して「レコード」って言うんや。

 

そしてSQLっていうDB専用言語を使って、必要な情報を取り出すってわけ。

SQLの命令は、

 

・何を

・・・マサの「誕生日」を

 

・どこから

・・・「マサのプロフ」テーブルと「AKB48のメンバー」テーブルから

 

・どのように

・・・誕生日が同じ、という条件で

 

取り出す。

 

ざっとこんな感じ。

これらをAppサーバとDBサーバがSQLを使って情報の受け渡しをしているんや。

 

情報が多くなってくるとこいつも最強にしなければならんな。

 

ちなみに使うとするなら「MySQL」とか「PostgreSQL」かな。

 

 

実際にISUCONで戦うとなると、CPUとメモリから判断してこの3つの内、どいつを最強(チューニング)にしていくかってことになる。

各サーバを1つのノードにまとめて入れるのか、それとも1ノード1サーバにするのか。

それぞれにMAXパフォーマンスを出させてあげて、それでも重くなるようだったらサーバ(ノード)分けてあげるとか。

まぁ色々パターンはあるみたい。

 

一般的な構成としては、WebサーバとAppサーバとDBサーバを1つのサーバ(ノード)にまとめて入れちゃうみたい。

 

ちなみに「オートスケール」っていう、自動でサーバを増やしたり減らしたりすることもできるみたい。

 

「あ、こいつやばいな。サーバ増やして負荷軽くしてやろう」

 

みたいな。

 

 

以上が「Webシステムの三層構成」。

女将さん・職人さん・素材屋さんのどれから最強(チューニング)にしていくのか、作戦会議をしながら進めるみたいです。

 

「プロになるためのWeb技術入門」終わり!!

(ISUCON出場に向けて、本書の全7章のうち5章までを読みました。)

 

 

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

 

 

 

「プロになるためのWeb技術入門」を読んで 〜Cookie〜

今日は「Cookie」について。

なんだか美味しそうだね。

ちなみにぼくはオートミールクッキーが好きですw

 

 

Cookieとは

 

Webブラウザに情報を持たせる技術。

WebアプリケーションとWebブラウザ間で情報を交換できる技術。

 

どーゆーことかと言うと、

ログイン情報とかの来訪履歴って感じかな。

 

 

ブラウザ:「こんちはー。」

サーバ:「いらっしゃいませー。お、初来店やね。じゃあ会員証(Cookie)やるよ。」

ブラウザ:「あざっす!」

 

 

ブラウザ:「やぁ、またきたでー。」

サーバ:「会員証(Cookie)確認おっけー。」

ブラウザ:「お、この前買い悩んでたものまだカゴに残ってるやんけ。」

サーバ:「せやで。おれってええ奴やろ。」

ブラウザ:「あざっす!」

 

 

Cookieはサーバからブラウザに送られる。

各アクションごとに情報が更新されてく。

例えば、

・ログイン時のユーザ情報登録で更新

・何か買ったら更新

みたいな。

 

こうやって毎回同じサイトにきた時にいちいちログイン情報を入力しなくていいわけやな。

うん、便利や〜。

 

でも、そんな美味しくて便利なCookieにも問題点があるんやと。

 

どうやらCookieはテキストファイルとしてPC上に保存されるらしい。

ダイアログをのぞけばそれが見れるんだって。

 

困ったな、どうしようか。

 

 

セッションID

銀行窓口の受付番号的なやつ。

 

「受付番号372番でお待ちのお客様、お手続きが完了いたしましたので窓口までお越しくださいませ。」

 

そう、これこれ。

こうすれば個人名呼ばれなくて済むよね。

 

******************

セッションID:372

名前:マサ

受付:完了

手続き:手続き中

完了:まだ

******************

 

このセッションIDをCookieに入れてサーバとクライアントがやりとりをするんやな。

結局のところ、Cookieを使うことに変わりはないからCookieの情報を分からなくしてやろうって考え方やね。

もちろんセッションIDはただの数字(または文字列)だから誰が見ても分からんというわけ。

 

 

イメージとしては、DBから取ってきた情報を変数に入れるイメージかな?

ここらへんはもうちょっと調べてみよう。

 

ではでは、今日はこの辺で。

 

 

「プロになるためのWeb技術入門」を読んで 〜HTTP〜

先ほどコンサル会社の2dayインターンシップを終えました。

ナメてかかったわけではないですが、予想以上に頭使いました。

ぼくのザコ脳内メモリでは荷が重すぎたみたいですww

 

 

んじゃあ、早速「HTTP」について。

 

HTTPとは通信プロトコルの一つで、「情報の伝達方法」と「情報の意味付け」を規定するものでしたね。

 

では、どうやって情報を届けるのか。

 

IPアドレス

を使うんやと。

192.168.0.1 ←これ

人間世界と同じ、住所ってことですな。

 

このIPアドレスがわかると宛先のホストが特定できて、そいつに情報届けることができるらしい。

その役割は

TCP/IP

っていうプロトコルがやってくれるんやと。

情報をパケットという小さな単位に分割して送受信している。

郵便屋さんみたいなやつやね。

 

ん、待てよ。

URLも住所だよな。

URLとIPアドレス、どっち使えばええねん!

 

 

DNS

Domain Name System

ほうほう、こいつが打ち込んだURLをIPアドレスに変換しているらしい。

 

クライアント:「www.dirty.jpのIPアドレス教えてくれや」

DNSサーバ:「187.149.198.45や。覚えときや。」

 

こんな風に問い合わせることもできるらしい。

 

しかし、ここで終わらないのがインターネットの奥深さ。

 

 

「ポート」

郵便屋さんのTCP/IPは受信した情報がどのようなプロトコルか、どのアプリケーションが処理すべきわからないんだって。(なんだよ、ただ届けるだけかよw)

そこでこの「ポート」、港を使って情報を待つんだと。

Aは第一港、Bは第二港みたいに、その情報がどのプロトコルかを識別しているわけやな。

ちなみにHTTPはポート番号80で、SSHは22らしい。(SSH、22はどこかで使った記憶が....)

 

だから正確な書き方としては

 

www.dirty.jp:80

187.149.198.45:80

 

になるんだけど「:80」は省略されるって。

 

 

最後に

「GET」と「POST」

 

これは情報の渡し方、パラメータの渡し方の違い。

 

ん、「パラメータ」ってなんぞや.....。

 

例えば、

http://www.dirty.jp/unko/brown.php?num1=10&num2=20

がある。(入力欄に10と20を入れている)

 

パラメータはこれで言う、「num1」と「num2」。

 

「10」と「20」は値。

 

「?」以下をクエリ文字列と言って、「パラメータ名=値」の形式で表されている。

 

おっけ、パラメータ分かった!www

 

 

話を戻すと、

http://www.dirty.jp/unko/brown.php?num1=10&num2=20

はGETでの渡し方。

 

POSTはと言うと、

http://www.dirty.jp/unko/brown.php

になる。

 

お、クエリ文字列がないやんけ。

 

なぜか。

 

答えは「セキュリティ」の問題。

アカウント作るときにユーザ情報を入力するでしょ。

それって個人情報やん。

パラメータとしてそれがURLに出てきちゃったらマズいよねって話。

だからGETとPOSTはちゃんと使い分けよう。

 

まとめるとこう。

 

「GETリクエスト」

・メソッド:GETメソッド

・パラメータの格納場所:URL

・セキュリティ:低い(サーバにログが残る)

・パラメータの長さ:制限の可能性あり

・パラメータの保存・再現:しやすい

 

「POSTリクエスト」

・メソッド:POSTメソッド

・パラメータの格納場所:メッセージ・ボディ

・セキュリティ:比較的高い(サーバにログが残らないことが多い)

・パラメータの長さ:制限なし

・パラメータの保存・再現:しにくい

 

 

ざっとこんな感じ。

 

 

 

ではでは、今日はこの辺で。

 

 

 

 

「プロになるためのWeb技術入門」を読んで 〜URL〜

 

前回記事の最後にURLの話をしたけど疲れちゃったので続きを。

 

matsuda-juri.hatenablog.com

 

まずはURLの構成から。

 

例えば

http:// www.dirty.jp/unko/index.html

ってのがあるとする。(汚くてすいません。)

 

「えいちてぃーてぃーぴーころんすらすら」のアレ。

これは大きく3つに分けられる。

 

・「http:」 → スキーム

リソースの取得方法を表している。

 

 

・「www.dirty.jp」 → ホスト名

リソースが存在するホストコンピュータ名を指している。

んで、このホスト名はまた2つに分けることができて、

 

  「www」 → ローカル名

  「dirty.jp」 → 親ドメイン

になると。

 

"jp" → 日本の

"dirty" → dirtyという組織の

"www" → WWWサーバというコンピュータ

 

って意味らしい。

 

 

 ・「unko/index.html」 → パス名

 ホスト名で指定されたコンピュータ上のリソースの位置を示す。

上で言うと、「unko」ディレクトリの下にあるindex.htmlというファイルを示しているんやと。

 

 

そうか、URLっちゅーのは

ドメイン → コンピュータ → ディレクトリ → ファイル名

で指定してるのか。

 

 

......ん、待てよ。

「http」ってなんぞや。

 

 

 

ざっくり言うと、「http」はお約束ごと。

サーバとクライアントが通信を行うときに、どうやって情報のやりとりするかって取り決めなんだと。

 

クライアント:「HTMLが欲しいんやけど、どうやってやりとりしようか?」

サーバ:「そうだね。HTTPでよくね。」

クライアント:「おっけ、じゃあそれで。」

 

みたいな感じかな。

この取り決めを通信プロトコルって言うそうな。

 

 

そういや昔「狼煙」ってあったよね。

遠くの人に情報を伝える手段の、あの煙や。 

 

狼煙は、

・煙を使って合図を伝えること

・敵の襲来を示すこと

・狼煙の煙を見たら、自分たちも狼煙を上げてさらに周囲の人に伝えること

 

これがプロトコル、狼煙の取り決めやったんやな。

やはり先人たちはすごい。

便利な世の中になったもんだ今は。

 

 

ではでは、今日はこの辺で。

 

「プロになるためのWeb技術入門」を読んで 〜サーバとクライアント〜

Lesson 2 「Webはどのように発展したか」

 

この章ではWebの歴史について。

ぼくは歴史が苦手なもんでここはさらっとww

 

そもそもインターネットは今から約40年ほど前にその原型ができたそうな。

けど利用者は大学とか研究機関の関係者で一般的ではなかったそうな。

よって当時のWeb技術はこの人たちから生み出されたんだって。

 

「WWW」という考え方もそう。

研究成果を全世界で共有できないかって思ったらしい。すごいね。

要はインターネット経由で研究成果を閲覧できるようになったわけだ。

しかも「HTML(hyper text markup language)」というコンピュータが理解できる統一形式も作っちゃった。頭良すぎやろ。

 

 

 

・WebサーバとWebクライアント

 いよいよ技術的な話。

 

WWWによるハイパーテキストの公開と閲覧は「Webサーバ」と「Webクライアント」というソフトウェアで実現されているんだって。 

Webサーバがネットワーク上にハイパーテキストを蓄積して、Webクライアントの要求に従って必要なHTMLファイルを渡してあげる仕組み。

 

つまりこう。

 

クライアント:「HTMLちょーだい」

サーバ:「はい、このHTMLだね。あげる。」

 

ほうほう、なるほど。エンジニアの人がよく言う

リクエスト投げてみ」。

 

これがクライアントの要求、つまり

「HTMLちょーだい」

だったんだね。

 

ってことはこのサーバの応答が

「レスポンス」。

 

けどさ、「HTMLください」なんて言わないよねwww

どのHTMLか分からんもん。

ってので出てくるのが「URL」。

 

・「そのリソースはどこにある?」 ーURL

 

例えばの話。

ぼくの友達に「マサ(仮・田中正志)」という人がいる。

日本の人口約1億2000万人の中からこいつを探し出すにはどうするか。

 

まずは「田中正志」で探してみよう!

.....うん、いっぱいいるよね。

 

じゃあ次は大学名を付けて「はてな大学 田中正志」で探してみよう!

......だいぶ絞れたけどマサじゃない奴も出てくるな。

 

よし、今度は学部名も加えて「はてな大学 ブログ学部 田中正志」だ!

......おっ、マサだ!!やっと会えたね、よしよしwww

 

こんな風に一意のコンテンツを特定するための仕組みが「URL」。

 

ふぅ、疲れたからURLの話は次回にまとめよう。

 

 

 

「プロになるためのWeb技術入門」を読んで 〜Webアプリケーションとデスクトップアプリケーション〜

ISUCON出場に向けてまずはこれを読む。

「プロになるためのWeb技術入門」。

www.amazon.co.jp

 

Lesson1 「Webアプリケーション」とは何か

ここでは「Webアプリケーション」と「デスクトップアプリケーション」の違いが説明されている。

 

「Webアプリケーション」とは....

①処理の主体:サーバ

②画面の表示:Webブラウザ

③インストール不要

 

「デスクトップアプリケーション」とは....

①処理の主体:手元のPC

②画面の表示:OS

③インストール必要

 

ざっくりとこんな感じ。

普段PC触ってるのであればわかるレベルかな。

 

では、今日はこの辺で。