アラフォーがお金持ちになるためエンジニア目指すブログ

お金も根性も学歴もないアラフォーまきのがエンジニアになってお金持ち目指すよ!

侍エンジニア塾 15回目の授業

どうも、アラフォーまきのです。
火曜日に授業が会ったばかりですが、11月の授業が1回お流れになった分の取り戻しを今日やりましたー。

今日もなかなかにボリューミーでしたー。
3時間20分。
忘れる前に書きましょう!

本当にボリューミーだったので、箇条書きで行きます。
正直、見てると眠くなると思うw
アホほど長くなります。まじで。

前回からの課題

・卒業制作、それのみ!
・火曜日から今日まで2日半くらいの時間だったので、とにかく仕様書を参考にページを追加。
・プルダウンメニューを作ろうとして、デフォ値の設定を考えていた。結論は出ず。
・今朝UPした記事の内容が作れた。
www.arafo-enjineer.net

今回の授業

作成時に疑問だったことを相談1:管理者用画面の考え方

  • ユーザーDBがあるから、そこに管理者フラグを追加
  • current_user且つ管理者フラグtrueなら、管理者画面を表示させればいい。
  • だから管理画面用コントローラを作ればOK
  • 既存のユーザーDBをつかうから、紐付けはもうできているので紐付けの追加はとりあえず必要なさそう。

作成時に疑問だったことを相談2:プルダウンの仕組み

  • プルダウンの選択肢の内容を、DBに格納されている「各ユーザーが任意に作った情報」にした。
  • でもそれ以外に、「全ユーザーに共通するデフォ値」を選択肢の最初に表示したい。
  • ひとまずpromptを使ってデフォ値を設定したけれど、これはDBにない値だから、IDがなくてエラーになる。
  • 全ユーザーに共通するけれど、DBへの格納時には【どのユーザー】の【どの項目】にこの選択肢の値をいれるかを指定しなければならない。
  • やり方は色々あるけれど、ここはコールバックを使おう。
  • コールバックは、before_actionのようなもの。
  • before_actionは、コントローラに対して「どのアクションよりも先にこのアクションを実行してね!」というもの。
  • コールバックは、モデルに対して「特定の動作(CRUD)があった瞬間に、この作業やってほしいよ」と伝えるもの。
  • CRUDは、CREATE,READ,UPDATE,DELETEのこと。
  • CREATE = HTTPでいうPOSTで、SQLでいうINSERT
  • READ = HTTPでいうGETで、SQLでいうSELECT
  • UPDATE = HTTPでいうPATCH(PUT)で、SQLでいうUPDATE
  • DELETE= HTTPもSQLでもDELETE
  • コールバックで、ユーザーが新たに登録された時(新規ユーザー登録された時=CREATEされた時)に、選択肢のデフォ値を追加する作業を入れる。
  • デメリット: たった1つの共通の項目がユーザー分だけ作られることになるので、容量を食う。
  • メリット:1つの選択肢を全ユーザーが使い回すわけではないので、不整合が起きない。わかりやすい。
  • 今回はbefore_createかafter_createのどっちかで、選択肢の項目を追加するメソッドを発動させればおk

4:HTTPとActiveResource

【まずはHTTPについて】

  • HTTPはプロトコロルだ
  • プロトコルは通信=鯖とか情報をやり取りする時の取り決めだ。
  • HTTPSはセキュアなプロトコルだ
  • セキュアってことは暗号化されて覗き見されないってことだ
  • 情報漏洩とか結構あったから、googleが「認証系だけにせず、全体的にセキュアにしよ。やってくれないサイトは検索結果あんまり優先しないよ」って言い出したもんだから、みんな頑張ってセキュア対応にしてる。
  • HTTPはURLとリクエストメソッドの2つの組み合わせが必要だ。
  • chromeなら、検証のNetworkを見てみるといい。
  • リクエストメソッドは、rails routesでいうところの【Verb】にくるもの。GET・POST・PUT・PATCH…。
  • リクエストされたら必ずレスポンスすることになっていて、その時の内容はステータス番号を返す
  • ステータス番号は「404 NOT FOUND」の404の部分

HTTPステータスコード - Wikipedia

  • ステータス番号は普段そこまで気にしなくていいけれど、自分がAPIを提供する側になった時、どのステータス番号を返すか自分が指示を書くことになるから、そのときには理解しているといい。
  • 小ネタとして【418 I'm a teapot(私はティーポット)】というステータスがあるw詳しくはググるといい。
  • 【414 URI Too Long】というステータスは、URL(URI)にはパラメータを含められるから、そこにでっかい情報を入れられてしまうと、paramsで受け取るときでっかい値を受け取らねばならなくて、これによりメモリ不足を起こし、アプリが落ちるなどの現象を防ぐため、エラーにしたとき発せられるステータス。
  • HTTPにも、HTMLのようにヘッダーとボディーが存在する。
  • 実は HTMLが動き出すより前に、HTTPのヘッダーが先にやり取りしていた。
  • 実は有効期限ってのもある。この期限内であれば、いちいちブラウザを見に行かず、自分のPCにキャッシュ(保存)された情報をみることでサクサク動かす。
  • URLはhttp://の次にあるのがhostと呼ばれるもの
  • hostはサーバーのこと。
  • DNS ドメインネームサーバーというものがある。ここで全てのサーバーの住所を把握している
  • サーバーの住所=IPアドレス
  • スマホやテレビなど、ネットにつながるもの全てにIPアドレスが付与されている
  • 実際には見えないけれど、例えばYahoo!のサイトを見ようとすると、まずはDNSにYahoo!の鯖=IPアドレスおしえてーと聞きに行く
  • DNSに「Yahoo!さんのIPアドレスは○○だよ」と教わってそこにつながりに行く。
  • ちなみに、すでにIPアドレスV4(version4)は枯渇して発行を終了している。
  • 今はV6(version6)になりつつある。こっちは天文学的な数あるのでおそらく枯渇はしない想定。
  • DNSが万が一悪刺されて、嘘のアドレスを教えるようになるとどえらい問題になる。(個人情報の抜き取りなどにつながる)だからDNSは徹底管理されている。
  • けれど、24時間365日、全世界が常にネットを使っているわけで、DNSがたった1つで対応しきれるわけがない。
  • 全世界いたるところにDNSのミラー=コピーがある。
  • コピーなので、大元のDNSは最新の情報を持っていても、コピー側がコンマ何秒の差で持ってないタイミングが存在するので、最新情報を渡せないデメリットがある。
  • コピーにはさらにコピーがあり、そのコピーがあり…とかなりの数ミラーが存在する。これだけミラー(コピー)があれば、当然中には残念なミラーができてしまうもの。
  • 信頼できるDNSを使わないと、改ざんされているかも…?
  • 先ほどのYahoo!のIPアドレスにたどり着くまでの道のりは、TCPプロトコルが活躍している。
  • 実は【スマホ】→【DNS】→【Yahoo!】みたいに単純ではなく、AWS(アマゾンWebサービス)みたいに海外に鯖があるような場合、いろんなサーバーを経由し、海を渡り、オハイオとかに繋がっていく。
  • DNSは到着地点は教えてくれるけれど、道順を教えるわけじゃない。
  • 道順は、TCPがプロバイダやルーター・いろんな鯖に「(到着地点)に行きたいけど、次はどの鯖に行けばいい?」と聞いていく。
  • ネットは「善意の塊であり、万が一嘘つきがいたり壊れた箇所があっても、その次の奴が正しいことを教えてやればいいだけ。いつかたどり着く」という考えがある。
  • 災害時などで一部ネットが寸断されても「あっち側から回ればいけるよ」とTCPが教わって、遠回りしてようやく目的のIPアドレスにたどり着く、ということがある。遠回りなのでつながるまで時間がかかるのはそういうこと。
  • portはRailsなら3000番を使っている。3000は割り当てなしにしてるから、自由に使っていいものとなっている。
  • Ruby on Railsで開発するときは、ローカルでやっているので3000にいつ誰が接続しても使える。
  • httpの場合は、ホストが80、httpsの場合はホストが443と決まっている。
  • ホスト=テレビのチャンネル
  • pathは今見ているサイトのTOPから下のアドレス。
  • 静的サイトなら、フォルダ/ファイルみたいな。

【本題のActiveResourceについて】

  • リソース=コンテンツのこと。HTMLやjpgなど。
  • URL=Uniform Resource Locator ユニフォーム リソース ロケーター。つまり、何かのリソース(コンテンツ)を指し示す"場所"
  • 「あの画像をみるためには、HTTPでhostが○○でportが□□でpathが△△へ…」と、そのリソース(ここでいう"あのがそう")の場所を示している。
  • URLを使うことで、そのリソースの場所が特定できるということ。
  • 正解に1つしかない。同じURLがあったら…?こまるよね。
  • HTMLリクエストメソッド+URLで、その場所にあるそのリソース(コンテンツ)に何をするか、が決まる。
  • リクエストメソッドがすでに何をするものか決まっている
  • 【DELETE /users/:id】と【PATCH /users/:id】は、リクエストメソッドがDELETEとPATCHで違うけれど、URL自体はどちらも【 /users/:id】
  • 同じURLでもリクエストメソッドがDELETEなら削除するし、PATCHなら置き換え=更新してくれる。
  • こうしてリクエストメソッドでやることはわかっているから、【DELETE /users/:id/delete】とは書かない。
  • createだけは、なぜか書くことになっている。これはなぜかRailsが最初のころにそう決めてしまったかららしい。
  • create以外についは、リクエストメソッドで何して欲しいかわかっているから、deleteやupdate・showなどを最後につける必要はない。
  • つけると動詞が二重になってしまう。一つ目がリクエストメソッド。PATCHですでに更新だって言ってんのに更にURLへupdateをつけると「更新で更新してくれ!」とイミフな内容に。日本語でおk。
  • ActiveResourceは、新規(new)・登録(create)・詳細(show)・変更(edit)・更新(update)・削除(delete)を1つずつ書かなくてもOKにしてくれる機能。
  • 基本の書き方に則るのであれば、resourcesでRailsがよきに計らってくれる。
  • 中には紐付けしたモデルの関係で、今いるコントローラから別のコントローラへリンクする場合があるが、そのようなイレギュラーの場合はresourcesでまかなえない場合があるので、普通に自分でURLを設定してあげればOK。

たとえば…。

  get '/users/:user_id/mokus/:id/work/new' => 'work#new'
  post '/users/:user_id/mokus/:id/work/create' => 'work#create'

次回までの課題

引き続き卒業制作をゴリゴリ進めます。
それだけ!

おわりに

ここまで読んだ猛者います?多分いないと思うんですよ。
万が一にも読んだ方いたらすごい。

ところで、仕組みを知るってたのしいですね!

私、アラフォーにして少し自分の性格が少し見えてきたんです。
どうも、知ることがすごく好きみたいなんだけれど、知って満足しちゃう感じみたいなんですよね。

それって知らないのと同じなんですよね。

知ったら、それを実践する。活かす。使う。役立てる。
知ったのに何もしないなんて、お金をただ貯金して寝かせてるのと同じ。

貯金はいつか使うかもしれない?
いやいや。お金はただの紙切れですよ。

ただし、そのお金という名の紙切れが、いろんなサービスと引き換えできるというだけ。

紙切れ保存してどうするんですか。使わなきゃ。
自分への投資に使わなきゃ。

それと同じことなんだって、最近いろんな人の発信をみていてわかってきました。

だから、知って満足せず、何かに使えるようにしたい。
そこを意識して行きたいですね。

今年も後の頃3週間。
もっと貪欲に言っていいのかもしれないと思いました。

また来週金曜日に侍塾です。
それまでにできる限りすすめなきゃ!

ではまたー!