■
とあるRuby勉強会に参加した。
印象に残った言葉や感想を書いておく。
触発されて僕も何やってたかまとめてみる。
## 勉強会まとめ
・開発環境を整える(エディタを使いこなす)
・写経など実際に書くのが学習効果高い
・本を読む実践のサイクル
・rails newの数だけ強くなれる
・Gemを読む
・bundle updateの差分を読む
・Railsチュートリアルが1番良い
・学習サイクル:言語仕様を理解→良い設計を考える
書籍
・初めてのRuby
・RailsによるアジャイルWebアプリケーション開発
・Railsの教科書
・Effective Ruby
・メタプロRuby
・パーフェクトRuby/Rails
・Webを支える技術
・ネーミングの掟と極意
・プリンシブルオブプログラミング
Webサイト
・Railsチュートリアル
・RailsGuide
・Rails API
## 自分の経歴
・工場労働者(3年)
・専門学校(2年)
・SIer(3年):ほとんどプログラム書いてない
・Webベンチャー(そろそろ2年):未経験入社
※Ruby歴は1年くらい。
## 学習の仕方
書籍
・Webアプリケーション開発
・パーフェクトRuby/Rails
・Webを支える技術
今も読んでるけどWebサイトは下記を読んでた
・Ruby Style Guide
・RailsGuide
・Ruby/Rails系のQiita記事
・肥大化したARをリファクタリングする7つの方法
https://techracho.bpsinc.jp/hachi8833/2013_11_19/14738
当初の状態
・最初期はRailsチュートリアル挫折した
・Rubyをなんとなく書ける
・Railsなんとなくわかる
・CRUDやRestfulわからない
もっとこうしたらよかったなと思うのは
勉強会でも出てたように言語仕様理解、フレームワーク理解、良い設計を考えるみたいな順番で進めることが出来たら理想だったのかもしれない。(あくまで理想、現実は同時進行)
「Webを支える技術」読書録
「Webを支える技術」を読んだのでまとめを作成する。
・REST
RESTとはネットワークシステムのアーキテクチャスタイルの1つ
RESTの構成
下記6つを組み合わせたアーキテクチャスタイル
・クライアント/サーバ :ユーザインタフェースと処理を分離する
・ステートレスサーバ :サーバ側でアプリケーション状態を持たない
・キャッシュ :クライアントとサーバの通信回数と量を減らす
・統一インタフェース :インターフェースを固定する
・階層化システム :システムを改装に分離する
・コードオンデマンド : プログラムをクライントにダウンロードして実行する
RESTの重要な概念の1つにリソースがある。
・リソースとはWeb上の情報のこと
・リソースはURIで一意の名前を持つ
・URIを用いることでプログラムはリソースが表現する情報にアクセスできる
・URI
URIとはリソースをと統一的に識別するID
「変わらないURIが最上のURIである」
URIの設計方針
・プログラミング言語依存の拡張子を使わない
・実装依存のパス名を利用しない
・プログラミング言語のメソッド名を利用しない
・セッションIDを含めない
・リソースを表現する名詞を使うべき
・TCP/IPとは
・ネットワークインタフェース層
物理的なケーブルやネットワークアダプタに相当する部分
・インターネット層
TCP/IPではIPの部分。データ送信を保証する。
ネットワークでデータのやりとりを行う部分。
IPではパケット単位でやりとりして通信する。
・トランスポート層
TCP/IPではTCPの部分。データ転送を保証する。
接続先の相手にコネクションを張ってデータの抜け漏れをチェックして保証する。
・アプリケーション層
メールやDNS、HTTPなどの具体的なアプリケーションを実現する。
・HTTPメソッド
GET:リソースの取得
POST:リソースの作成・追加
PUT :リソースの更新・作成
DELETE:リソースの削除
HEAD:リソースのヘッダ(メタデータ)の取得
OPTIONS:リソースがサポートしているメソッドの取得
POSTとPUTの使い分け
・POSTでリソースを作成する場合は、クライアントはリソースのURIを指定できない。(URIの決定権はサーバ側にある)
・PUTでリソースを作成する場合は、クライアントがリソースのURIを指定する。
べき等性と安全性
・べき等性:ある操作を何回行っても結果が同じこと
・安全性:操作対象のリソースに副作用がないこと
GET、HEAD:べき等性かつ安全
PUT、DELETE:べき等だが安全でない
POST:べき等でも安全でもない
ステータスコード
・1xx:処理中
・2xx:成功
・3xx:リダイレクト
・4xx:クライアントエラー
HTTPヘッダ
概要
・メッセージのボディに対する付加的な情報(メタデータ)
・ヘッダの情報を元にクライアントやサーバは挙動を変化させる
具体的に実現してる機能
・リソースのアクセス権を設定する認証
・クライアント・サーバ間の通信回数と量を減らすキャッシュ
JSON(JavaScript Object Notation)
・JavaScriptの記法でデータを記述できる
・データ型:オブジェクト、配列、文字列、数値、ブーリアン、null
JSONP(JSON with Padding)
・Ajaxで用いるXMLHttpRequestというJavaScriptモジュールは取得サーバと同じサーバ内でしか通信できない。
別のサーバと通信できてしまうと、ユーザが知らない間にデータを不正なサーバに送信できるというセキュリティ上の問題が発生するから。
この問題を解決するために、HTMLのscriptタグでJavaScriptファイルを読み込んで、その中に書いてある関数をクライアントが任意のタイミングで呼び出して
クロスドメイン通信を実現する手法がJSONP
・リソース指向アーキテクチャ設計
1)Webサービスで提供するデータを特定する
2)データをリソースに分ける
3)リソースにURIで名前をつける
4)クライアントに提供するリソースの表現を設計する
5)リンクとフォームを利用してリソース同時を結び付ける
6)イベントの標準的なコースを検討する
7)エラーについて検討する
RESTfulなWebサービスの性質
・アドレス可能性
・接続性
・統一インタフェース
・ステートレス例
バルクアップデート
・リソース全体を送信して更新する方法
パーシャルアップデート
・リソースの一部分を送信して更新する方法
設計のバランス
・なるべくシンプルに保つ
・困ったらリソースに戻って考える
・本当に必要ならPOSTで何でもできる
リソース設計の手法
・関係モデル
・オブジェクト指向モデル
・情報アーキテクチャ(相性が良い)
WebサービスとWebAPIを分けて考えないことがリソース設計で最も重要