さぼさんのGit講座を受けました 〜Git〜
こんばんは。
先ほどココイチで「馬モツ煮込みスクランブルエッグカレー500g」を食べて今日という1日を終了させようとうしています。
ですが
昨夜はさぼさんの3.5時間にも及ぶGit講座を受けたので、これをまとめないわけにはいかない。
ってことで、今回はGitのまとめしまーす。
と、その前に
先にマサが書いているのでそちらもどうぞー。
Gitってなぁに？？
Gitとは、ソースコードの変更履歴を管理するもの。
実は、Gitを作ったのはLinuxの開発者なんです。
その開発者が、Linuxを全世界の人と共有し、開発してブラッシュアップしていこうってことでGitができた背景があるみたいです。
Gitを使った一連の流れ
ここから実際にさぼさんに教わったGitの使い方をまとめていきやす。
まずはターミナルを開きます。
$cd でホームディレクトリに移動し、
$mkdir Git_practice でディレクトリを作り、そこに移動。
移動できたら上のコマンド。
この 「git init」はそのディレクトリ配下をGitの管理下にする。
つまり、このディレクトリで変更したり、追加・削除したファイルは履歴に残せるというわけ。
また、ディレクトリ直下にgitファイルがつくられる。
※test.txtは作っておきます
すると、「.git」が作られてるのがわかりますね。
ここでtest.txtをてきとーに変更し保存。
ターミナルに戻り、
これでcommitの準備完了。
そしていざcommit！
この時メッセージを添えますが、その内容は変更点の内容がざっくりわかるようなものがいい。
例えば、「ログイン機能実装」とか「バグ修正」とか。
これで変更履歴をローカルに残すことができました。
ここで $tig というコマンド打ってみよう。
すると
こんな画面が出ます。
これは、commitのログ的なやつ。
的なやつというか、それですww
ここで追加したコードとか差分が見れる。
例えば、緑文字の
「+ISUCON2017」
は、「ISUCON」が「+」、つまり追加されたということがわかる。
このtigの使い方は、
「あれ、あの時どんな変更したっけ？」
とか
「あの時のコードに戻したい」
みたいなときに使える。
使い方はvimみたいな感じで、
j：下に進む
k：上に進む
q：終了・戻る
で操作する。
ここまでが一連の流れ。
おさらいすると、
1. 「git init」 でgit使えるようにする
2. ファイル変更
3. 「git add 変更したファイル」でcommitの準備
4. 「git commit -m "メッセージ"」で履歴登録完了
こんな感じですかね。
もうちょいGit使いこなそうぜ
さっきの続きから。
Atomを開いて、てきとーに変更して保存。
ここでは add も commit もまだしていない状態。
ここでgitの状態を確認したい。
そんなときは $git status
するとこの画面。
赤文字で「modified」と出てる。
これは「変更してるファイルがあるよけど、まだaddしてないよー」って意味。
ここで
「あれ、どこ変更したんだっけ？」
ってなったらどうするか。
そんなときは、 $git diff
これは、直前のcommitから現在の変更した部分の差分を見るもの。
これでOKだったらaddしてcommitすれば完了。
ファイルの状態ってどうなってんの
「untracked」ってのは、「gitがまだ知らないよー」ってこと。
つまりファイルを新しく作った時とかやね。
「unmodified」は「変更なし」。コミット直後とかこうなるね。
「modified」は「変更した」。
「staged」は、「addはしてるけどcommitまだやねー」。
つまり「commit準備完了」ってとこかな。
今回はさぼさんによる基本的なGitの使い方をまとめました。
今までなんとなくGit使ってたけど、コマンド叩くだけであんま理解してなかったなぁww
そんな頭空っぽのぼくにGitを叩きこんでくれたさぼさん、超絶アザッス！！！！！！
ってことで、次回は「GitHubの使い方」。
ではでは、今日はこの辺で。
「中間テーブル」ってなんぞや
こんばんは。
今日は、今朝に就活先の会社から「次の選考に進んでください」連絡が入り、さっきさぼさんに大学近くの油そばご馳走になって、お腹も気分も満たされた良い1日でした。
と言いたいところですが、1つだけ満たされないことが。
そう、タイトルの通り、「中間テーブルってなんぞや」問題です。
今日締め切りだった課題の「LINEを作る」は、この中間テーブルに手こずって未完成となってしまいましたが、なぜか次の選考に進めるみたいですww
（冒頭に書いた会社とは別です）
もちろん、このまま未完成に終わるのは悔しいので最後まで完成させます。
ってことで今回は「中間テーブル」についてまとめていきます。
中間テーブルってなんぞや
例えばの話。
学校の授業を思い出してください。
国語やら算数やら体育やらありますよね。
んで、もちろん生徒は１人ではなく３０人ぐらいいます。
マサは国語と算数と理科と社会の授業に出てる。
ディックスくんは国語と算数と体育と図工。
（おめーらもっと授業出ろよww）
このとき、「isucon_school」というデータベースには
・studentsテーブル（学籍番号、学年、名前、性別、etc）
・lessonsテーブル（科目名、先生の名前、教室、etc）
があるのはなんとなくわかりますね。
さて、先生は「どの授業に誰が出てるか」を知りたい時どうすればよいのか？
そもそも、1つのレコードに対して各データ項目は1つしか入らないんです。
けど、国語の授業にはマサとディックくんの複数人がいる。
逆に、マサは4つの授業受けてるし、ディックスくんもそう。
つまり、「多：多」の関係なんです。
（かなり説明省いてます。すいませんww）
ってことで、あら困った。
これを解決してくれるのが、やっと出てきた
「中間テーブル」
なんです。
話を戻すと、先生が知りたかったのは、
「どの授業に誰が出てるか」
でした。
ってことで、「studentsテーブルの名前」と「lessonsテーブルの科目名」を紐付ければよさそうです。
この紐付けによってできたテーブルが「students_lessonsテーブル」で、「科目名」と「名前」のデータを持つ中間テーブルとなるわけです。
と、理解できたのはここまでww
実際に開発していこうとすると分からなくなり発狂しそうです。
ってことで、今回は中間テーブルについてでしたが、ぼくとしてはDB設計の大切さについて学んだ感じでした。
ではでは、今日はこの辺で。
松田、LINEを作るってよ
こんばんは。
夜中の２時でもギンギンのビンビンで開発してます。
何を作ってるかと言うと、「LINE」
というのも、就活先の企業の選考課題なんです。
本来ならRailsで作りたいところですが、あくまでISUCONの勉強として今回はSinatraを使います。
これがまたむずい。
特にデータベース。
今回mysqlを使っていますが、今までほぼ触ってなかったので全然わからん。
ちょうど今、1:1のトークができるように複数のテーブルを繋ぐみたいなことしてますが、「中間テーブル」なるものの存在を初めて知り、悪戦苦闘中です...。
そしてもっとわからないのが「Pry」
完全にここでハマったので、気分転換にこれを書いてる次第ですww
自分でもあんまりわかってないけど、やっぱり動くと嬉しいし、コードが読めて書けるようになるのは成長の実感が湧くからいいですね。
提出期限は5月15日の昼12時まで。
この場で披露できるように頑張ります。
あ、せっかくなのでGitHub載せまーす。
よし、もう少しやろう。
R.I.P.マギー, Welcome ディックス
こんばんは。
本日２度目の投稿ですwww
突然ではありますが、早速メンバーの入れ替え事案が発生しました。
マギー、逝く
タイトルの通り、マギーが逝きました。
「逝った」と言っても、彼は死んだわけではありませんwww
やりたいことがあるんだと。
まぁ、こういうことですwww
あ、やりたいことってのはラーメン屋じゃなくて、もっと大っきくて壮大なことらしいです。
我々としても彼のやりたいことはできるだけ応援したい。
君の分まで頑張るからね。
R.I.P. マギー。
さて、１人いなくなってしまった。
どうする。
ようこそディックス
なんてことはございません。
マギー脱退が決定して数秒後の様子がこちらです。
はい、即確保wwwwwwwwwwwww
その名もディックス
由来は...はい、「dick」からきてますwwwwwww
「正真正銘のディックス」
彼はこのTシャツを着てきましたwwwwwwwww
実はディックス、マサの高校の後輩なんですよ。
あと色々話聞いてると、すでに大学の単位150ぐらい取ってるとか、エストニア留学するために休学中とか、パソコン教室通ってるとか。
色々と活動的な面白いやつです。
ってことでディックスを迎え入れました！
すでに正式メンバーとして、着々と課題をこなしています。
そしてチーム名も決まりました。
その名も
「仕事ください」
ww
新体制となったチーム「仕事ください」。
みなさまにはどうかまた、温かく見守っていただけるとありがたいです。
よろしくお願い申し上げます。
・ディックス
「Webを支える技術」を読んで 〜HTTPの基本〜
こんにちは。
世間はGWですが、人権のないぼくにそんなものはありませんww
ここ最近滞っていたアウトプットを一気にしたいと思います。
あと、メンバーの小ネタも別記事で書いていこうかなと.....wwww
では、いきまぁっぁあぁぁす！！！！
前回は「URI」のお話でした。
今回からはwebを支える技術の３本柱の１つ、「HTTP」についてまとめます。
HTTPの基本
ここで１冊目の「プロになるためのWeb技術入門」をおさらいすると、
TCP/IPは郵便屋さんの役割やったね。
情報をパケットという単位に分けて送受信しているんやった。
ここら辺の話をもうちょっと詳しくすると、インターネットのネットワークプロトコルは階層型になってるそうな。
んで、その階層ごとに担当するプロトコルがある。
どういうことかと言うと
・アプリケーション層
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
・インターネット層
→ IP
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
・ネットワークインターフェース層
→ イーサネット
IPが担当するのは下から２番目の「インターネット層」。
ここでは、パケットという単位に分割してデータを実際にやりとりするんや。
ちなみにこいつは「データを送り出すだけ」しかやらないらしいwww
そしてTCP 。
こいつはその上の「トランスポート層」を担当。
ここでは、IPが送り出したデータをTCPが転送する。
TCPでは接続先の相手に対してコネクションを張る。
このコネクションを使ってデータの抜け漏れをチェックしているんや。
んで、接続したコネクションで転送するデータが、どのアプリケーションに渡るかを決定するのがポート番号 。
ちなみにHTTPは８０番やったね。
ここまでまとめると、
①インターネット層でIPがデータをトランスポート層に送り出す、
②トランスポート層に渡ってきたデータを、TCPがポート番号で指定されたアプリケーションに転送する
こうやね。
HTTPの仕組み
基本的な仕組みは、「クライアント/サーバ」。
クライアントが出したリクエストをサーバで処理してレスポンスを返すというもの 。
この時、クライアントがやっているのは、
・リクエストメッセージの構築
・リクエストメッセージの送信
・（レスポンスが返るまでの待機）
・レスポンスメッセージの受信
・レスポンスメッセージの解析
・クライアントの目的を達成するために必要な処理
めっちゃ色々やっとるやんw
んで、同じくサーバがやっているのは、
・（リクエストの待機）
・リクエストメッセージの受信
・リクエストメッセージの解析
・適切なアプリケーションプログラムへの処理の委譲
・アプリケーションプログラムから結果を取得
・レスポンスメッセージの構築
・レスポンスメッセージの送信
HTTPの性質
HTTPの重要な性質の「ステートフル性」。
Cookieとかセッション状態とか出てきたけどもうちょっと詳しく。
ハンバーガーショップの例。
・ステートフルなやりとり
店員：「いらっしゃいませ。ご注文は？」
マサ：「セブバーガーセットで。」
店員：「サイドメニューは？」
マサ：「ポテト」
店員：「ドリンクは？」
〜〜〜〜省略〜〜〜〜
店員：「以上でよろしいですか？」
マサ：「はい。」
店員：「かしこまりました。」
.....うん、普通やねwww
ぼくらの日常会話はステートフルな会話ってことやな。
んじゃ、ステートレスなやりとりとは？
・ステートレスなやりとり
店員：「いらっしゃいませ。ご注文は？」
マサ：「セブバーガーセットで。」
店員：「サイドメニューは？」
マサ：「セブバーガーセットをポテトで。」
店員：「ドリンクは？」
マサ：「セブバーガーセットをポテトとコーラで。」
〜〜〜〜〜〜〜〜〜〜〜省略〜〜〜〜〜〜〜〜〜〜〜
！？、マサがめんどくさい＆ラリってるwwww
なるほど、ステートレスなやりとりってのは、毎回全ての注文を繰り返さないといけないわけやな。
一方のステートフルなやりとりでは、店員が毎回の注文を覚えているんやね。
このやりとりはweb上だと、クライアント（マサ）/サーバ（店員）になる。
一見ステートフルなやりとりの方がイケてるように見えるが、実はそうでないらしい。
ステートフルの欠点は、クライアントが増えるにしたがって、サーバが毎回のリクエストを覚えることが難しくなってくる。
ステートレスはこの点を解消している。
最終的なリクエストは、「セブバーガーセットのポテトとコーラ」。
それまでのやりとりをサーバが忘れていても、リクエストメッセージにこれがあれば、サーバはちゃんと認識してくれるってわけやね。
けど、ステートレスにも欠点がある。
それは、いちいちリクエストを送らなければならないので
「送信するデータが多くなる」。
これはパフォーマンス低下につながる。
まとめると、
ステートレスなアーキテクチャはスケーラビティの面でめっちゃ優秀だけど、パフォーマンス低下の欠点もある。
ってことやな。
次回は「HTTPのメソッド」について。
ではでは、今日はこの辺で。
「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ってわけやな。
細かいとこは実際に触りながら覚えていくとしよう。
では、今日はここまで。
