ログインを実現するセッションとクッキー
今までもRuby on Railsで作成したアプリケーションに、ログイン機能を実装していたのですが、Gem(Devise)を利用して実装してきたこともあり、裏側でどんな処理がされているのかというのが、全く理解できていなかったため、WEBアプリケーションのログイン機能で使われるクッキーとセッションの基礎を学習したので、稚拙ではありますが、備忘録としてまとめます。
・セッションとは
状態を保持するための、ブラウザとサーバーとの接続状態の呼び名。
・なぜセッションが必要なのか
以下のように記述がされています。
HTTPはステートレスなプロトコルです。文字通り「ステート (state)」が「ない (less)」ので、HTTPのリクエストひとつひとつは、それより前のリクエストの情報をまったく利用できない、独立したトランザクションとして扱われます。
つまり、HTTPリクエストでは、ログインしているのかしてないのかといった「状態」を持たせることができない。
そのため、ログイン状態を保持する為に、セッションで状態についての情報を保持する必要がある。
・クッキーとは
クッキーは、ブラウザ(クライアント)側に備わっている、ブラウザとサーバのやりとりの情報を記録することができるもの。
クライアント側が情報を持っているので、たとえブラウザを閉じたとしても、記録した情報は、破棄されない。
しかしクライアント側でクッキーの中身をみれるので、暗号化する必要がある。
・なぜクッキーが必要なのか
こちらについてもRailsチュートリアルに以下のように、詳しく記述があります。
Railsでセッションを実装する方法として最も一般的なのは、cookiesを使用する方法です。cookiesとは、ユーザーのブラウザに保存される小さなテキストデータです。cookiesは、あるページから別のページに移動した時にも破棄されないので、ここにユーザーIDなどの情報を保存できます。アプリケーションはcookies内のデータを使用して、たとえばログイン中のユーザーが所有する情報をデータベースから取り出すことができます。本節および8.2では、その名もsessionというRailsのメソッドを使用して一時セッションを作成します。この一時セッションは、ブラウザを閉じると自動的に終了します2。続いて8.4では、Railsの別のcookiesメソッドを使用して、もう少し長続きするセッションを追加します。
先述の通り、クッキーは、たとえブラウザを閉じたとしても、記録した情報は、破棄されない。
ログイン機能で考えると、ログインしている状態でブラウザを閉じて、もう一度ブラウザを立ち上げても、ログイン状態が維持されるということが実現できる。
KJ法によるサービスアイデア発想法
少しネットで検索してみるとわかるのですが、アイディアの発想方法については本当にたくさんの方法が提唱されています。
その中で、個人的にとっつきやすく理解がしやすかったKJ法という手法をご紹介したいと思います。
KJ法
KJ法はアイディアを発想をするための「情報整理フレームワーク」として使われています。
まずブレストでアイディアを出し、挙がった各アイディアをグルーピングして行くことで、新しいアイディアの発想の手がかりを掴みます。
基本的な手順は以下の通りです。
1. 単位化(ブレスト)
具体的ではない、アイディアの素案をひとつひとつ書き出していきます。
グループでおこなう場合は、ブレスト(ブレインストーミング)をおこないます。
ブレストとは、 グループによるにアイディア発想法の1つで、参加メンバー各自が自由奔放にアイディアを出し合い、多数のアイディアを生み出そうという集団思考法・発想法のことです。
実際におこなうときは「ポストイット」などにアイディアを書いていくと効率的です。
2. グループ化
アイディアの意味や文脈が近い感じのものをグルーピングしていきます。
実際には、ブレストで書き出した全てのポストイットを目を通して、グルーピングしていきますが、この時にどのアイディアともグルーピングできないものは無理にグルーピング化しません。
グルーピングできたものに関しては、そのグループを言い表すような意味合いのラベル(タイトル)を書いたポストイットをそのグループの一番上に貼り付けます。
全てのラベルを貼り付けたら、もう一度全体を見直しておきます。
ここまでのブレストとグルーピングは納得するまで何度も繰り返していくことが、いいサービスアイディアを生み出すポイントのようです。
3. 図解化
先ほどグルーピングで作成した各グループに対して、意味や文脈の近いものを近くに、遠いものを遠くへと並び替えていきます。
そしてさらに大きな枠組みで、大グループを作成します。
この時に、先ほどと同じように大グループに対してもラベル(タイトル)を貼り付けます。
次にそれぞれの大グループの相関図を矢印などを用いて記述していきます。
実際には、ホワイトボードや模造紙などに貼り付けて記述していくのが効率的です。
相関性を記述するポイントは、通常以下のような項目があります。
- 原因
- 結果
- 因果
- 類似
- 反対
この相関性を記述すれば最後は文章化を残すのみです。
4. 文章化
ここまでは、あくまで情報の整理をおこなっただけなので、これを元に誰でも理解できる形で文章化をおこないます。
この文章化をおこなうことで、新たなサービスアイディアの着想を得ることができます。
文章化する際には、全ての大グループについて記述する必要はなく、相関性で結ばれているものを中心にして、ひとつなぎの文章で書き出していきます。
相関図から直接文章化するのは、難易度の高い作業になるので、コツとしては、一度断片的に箇条書きにして、それをひとつひとつ接続詞で繋げながら、文章を作っていきます。
以上が、KJ法の手順となりますが、この方法で最終的に完成した文章は、単なる思い付きのアイディアではなく、新たなサービスアイディアそのもの、そうでなくても新たなサービスアイディアのきっかけとなるはずです。
アメリカのドラマ「シリコンバレー」にハマった
最近毎晩アメリカドラマ「シリコンバレー」を観ています。
世界的なIT企業の本社や、スタンフォード大などがあり、起業家や投資家、ベンチャーキャピタルが数多く集まる「シリコンバレー」を舞台にしたドラマで、
アメリカでは、権威のあるエミー賞に2年連続ノミネートされていたりして、とても注目が集まっています。
ストーリーとしては、主人公とその仲間たちが、スタートアップを立ち上げて四苦八苦する姿と、スタートアップの成長をコミカルに描くような内容なのですが、
ディテールがすごく細かくて、アメリカのITバブルな感じがとてもリアルです。
そしてIT業界の専門用語が、説明もなく次々出てきます。
アメリカで働く人だけでなく、自分のように日本のIT企業で働く人間も少しクスッと笑ってしまうようなネタが出てきます。
Railsの処理の流れ
自分の頭の整理のためにも、ざっくりしたRuby on Railsの処理の流れを図解してみました。
ざっくりとしたチャートですが、自分としては、この流れを頭に入れることで、実際に作業する際もイメージしながら進めることができるようになりました。
O/Rマッピングについて
オブジェクトリレーショナルマッピングの略されたこちらの言葉ですが、
アプリケーションが持つリッチなオブジェクト(O)をリレーショナルデータベース2018/01/04/131719(RDBMS)のテーブルに接続するもの。
Ruby on Railsの世界にある「Model」と、RDBMSの世界にある「データベース」では、使う言語に違いがあり、データベースでは「SQL」という言語を使用する。
しかしこのO/Rマッピングをおこなうことにより、SQL文を直接書く代りにRuby on Railsのわずかなアクセスコードを書くだけで、SQLに翻訳されて、アプリケーションにおけるオブジェクトの属性やリレーションシップをデータベースに保存したり、データベースから読み出したりすることができるようになる。
参考:
Ruby on RailsにおけるRDBMSの仕様と基礎
そもそもRDBMSとは?
RDBMSは、リレーショナルデータベース管理システムの略で、
つまりは「リレーショナルデータベース」を管理するためのシステムです。
※PostgreSQL、MySQLなど
リレーショナルデータベースは、データをカラム(列)と、レコード(行)の中に入れて、テーブル(表)に並べるものです。(※個人的には、エクセルファイルを思い浮かべるとイメージしやすいです。 )
カラムとレコードの位置で、データの抽出などが効率的におこなえます。
またテーブルが複数存在する場合でも、あらかじめ割り振られたIDや主キーとなる項目を利用して、データ同士を関連付けることにより、テーブルを内部結合してひとつのテーブルであるかのように扱うこともできます。
このときRDBMSでは、データベースとのやり取りに、SQL言語が用いられます。
データベースの正規化とは?
データが複数の箇所に散在したり、データが重複するという状況にならないよう、整合的にデータを取り扱えるようにデータベースを設計することを、データベースの正規化といいます。
正規化をおこなうことで、運用時のデータの追加・更新・削除などの作業をおこなう際に、データの不整合や喪失が起きるのを防ぐのと同時に、メンテナンス性を向上させることができます。
RailsにおけるRDBMSの使い方
database.ymlファイルに、ユーザ名とパスワードなどの情報を記載する。
↓PostgreSQLの場合の一例
上記の設定を行い、database.ymlとActiveRecordを介してRDBMSへのアクセスをおこないます。
データの参照、追加、更新、削除などの全ての作業は「SQL」にて行う。
しかしRailsでは、直接SQLを描かなくとも、ActiveRecordの機能によって、コードをSQLに翻訳し、RDBMS内で実行させることができます。
↓Ruby/Ruby on RailsのコードからSQL文への翻訳の一例
Ruby/Ruby on Rails | SQL |
rake db:create | CREATE DATABASE ・・・ |
rake db:migrate | CREATE TABLE ・・・ |
Blog.all | SELECT * FROM blogs; |
Blog.find(1) | SELECT * FROM blogs WHERE id = 1; |
・アソシエーションとは
あるテーブルのデータに紐づく別のテーブルのデータを取得したい時に、
それぞれのモデルとモデルを関連づける、アソシエーションをおこなうことで、実現することができます。
詳細については、下記のオフィシャルガイドに詳しく記載がありましたので、こちらをご参照ください。
Modelクラスとデータベースとの紐付けについて
恥ずかしながら、Modelクラス(Active Record)と、データベースってどうやって紐付けされてるの?という部分を疑問に思っていました。
rails g model hoge
とターミナルで入力すれば、Modelファイルとマイグレーションファイルが出来上がるというRailsの機能が便利すぎて、逆にどうやって紐付けされてるのかという部分が理解しきれていませんでした。
Active Recordには、Modelクラスの命名規則があり、データベースのテーブル名を見つけるときに、モデルのクラス名を複数形にしたものを使用する。
つまりModelクラス名をHogeとした場合、これに対応するデータベースのテーブル名は複数形のhogesになる。
また、このRailsの複数形化させるシステムはかなり優秀らしく、不規則な名前であっても複数形にしたり単数形にしたりできる(person→peopleなど)。
また、モデルのクラス名が2語以上の複合語である場合、キャメルケース型(CamelCaseのようにスペースなしでつなぐ)という記述にするというルールがあり、その場合、テーブル名が(camel_caseなどのように)小文字かつアンダースコアで自動で区切られる形になる。
下記のRuby on Railsの公式ガイドの「Active Record の基礎」にもっと詳しく記載されています。
【余談】
Railsの学習を始めてから、早くも1ヶ月が経過しました。
たった1ヶ月で形になるものが作れるようになれると思っていなかったですが、簡単なものではありますが、なんとか形になるものを作成することができています。