Cookpad Summer Internship 2019 Day 1 Ruby TypeScript

Transcript

1. Day 1 Web開発基礎 赤松 祐希
2. Ruby
3. ゴール • 簡単なWebアプリケーションの実装を通してWeb開発の要素技術に触れる • ちょっとしたWebアプリケーション「フレームワーク」であれば自作できそうと思っ て欲しい ◦ 個々の要素技術の詳細よりは、それぞれの関係性や概念的なところを掴ん で欲しい
4. Ruby基本文法
5. rbenv • Rubyのバージョンを切り替えるツール ◦ cpadインストール時に自動で入っています • 今回はRuby 2.6.3 を使用するので rbenv経由でインストール ◦ rbenv install 2.6.3 ◦ rbenv global 2.6.3 rbenv影響下全体で有効 ◦ rbenv local 2.6.3 実行したディレクトリ以下で有効(globalより優先される) ▪ .ruby-versionというファイルが生成される
6. bundler • プロジェクトで使うgem(RubyGems)を管理 • 使用するgemを明示できたり、バージョンを指定できたりする • rubygems.org以外でホストされているgemをインストールすることも可能 ◦ 例えばGitHub • gemの雛形を作る機能などもある
7. Rackアプリケーション • RailsやSinatra、多くのRuby製Webフレームワークの理解においてRackという のが非常に重要 • Rackアプリケーションとして実装すると、様々なアプリケーションサーバーに対応 することができる ◦ 例: Unicorn、Puma
8. Rackが登場した背景 • 今までに多数のアプリケーションサーバーが登場してきた(恐らくこれからも) ◦ Puma、Unicorn、Thin、etc… • より良いアプリケーションサーバーが登場したときに、アプリケーションの改修コ ストを払いたくない! ◦ お互いにRackに対応することでコストが不要になる • 元々はPythonで策定されたWSGIというアプリケーションサーバーとアプリケー ションの仕様が元になっている
9. ブラウザからの処理の流れ • Rackがアプリケーションとアプリケーションサーバーを仲介することで、アプリ ケーションとアプリケーションサーバーが依存せずにすむ
10. Rackアプリケーションの仕様 • callメソッドが定義されていること ◦ callメソッドは環境変数を引数として受け取る ◦ 環境変数にはHTTPリクエストのメソッドやパスが含まれている • callメソッドの返り値は以下の3つを含むArrayであること ◦ HTTPステータスコード ◦ HTTPヘッダ ◦ HTTPメッセージボディ
11. HTTPリクエストとレスポンス • クライアントからサーバーに「何を」「どうして欲しい」か指示するのがHTTPリクエ スト ◦ 何を = パスで表現 ◦ どうして欲しい = メソッドで表現 ▪ GET=取得 POST=作成 PATCH=書き換え DELETE=削除 • それの返事がHTTPレスポンス ◦ どういう結果になったか = ステータスコード ▪ 200系=成功 300系=移動とか 400系=クライアント起因の失敗 500系= サーバー起因の失敗 ◦ 内容 = ボディ
12. サーバーサイドアプリケーションとは • HTTPリクエストを受け取り、何かしらの処理を行い、HTTPレスポンスを返すア プリケーション • ブラウザベースであればボディにHTMLを、APIであればJSONを入れて返すこと が多い • 最近はJSによるSPAなどもWebアプリケーションと呼ばれていると思うので、意 図的に「サーバーサイド」アプリケーションと表現しています
13. 演習: Rackアプリケーションを書いてみよう • Rackアプリケーションを実装し、サーバーアプリケーションに「最低限」必要な要 素をつかむ • 演習用資料のSection 1をやってみよう
14. ルーティングの導入 • サーバーアプリケーションが「何をするか」はHTTPリクエストのパスとメソッドで 大体決まる • 例題ではRack::Requestのpath_infoとrequest_methodで処理を振り分けた • 今後エンドポイントが触れるにつれ分岐がどんどん増えていくので、コードの見 通しをよくするためルーティングを導入する • ルーティングとはリクエストされたパスやメソッドに対して、それを処理するため のコードを割り当てること ◦ 厳密に言うとすでにルーティングしているが、もう少し構造だったものを実装 したい
15. Controller • 例えばRailsであれば /users にリクエストがあった場合 UsersController で処理 するというのが基本 ◦ RESTfulとかリソースとかの話があるが今日は割愛 • 今回もRailsにならってパスごとに処理するControllerを用意する
16. 演習: Controllerの実装 • Section 2に従いControllerの実装を行う
17. View • レスポンスに含めるHTMLをもう少し複雑なものを扱えるようにしたい • Rubyスクリプト内に文字列として埋め込むことも可能だが可読性に問題がでるこ とが予想できる • そこでViewのファイルをapp.rbとは別の場所に切り出して記述できるようにする
18. テンプレートエンジン • 今回はERBを使用する ◦ Embedded RuBy の略 ◦ テキストファイルにRubyを埋め込むことができる • 他にもHamlやSlimなどがある ◦ こちらの方が記述量が少ない、HTMLの閉じタグ忘れを防げるなどの理由 により一般的 • サーバーサイドアプリケーションを作る場合、Viewを動的に生成したいことがほ とんどなので何かしらのテンプレートエンジンを使うことが多い
19. 演習: Viewの実装 • Section 3に従いViewを実装する
20. Model • ControllerからViewに値を渡して表示できるようになった • そこで今度はデータベースから取得した値を表示するよう対応したい
21. リレーショナルデータベース(RDB) • Webフレームワークでは一般的なデータストア ◦ MySQL、PostgreSQLなど
22. SQL • RDBにおいてデータの操作や定義を行うためのクエリ言語 • ORM(後述)の登場によって、アプリケーション上に直接記述する機会は減ってき ているが、SQLを理解しておくことは重要 • ORMがどういうSQLを発行しているのか理解しておく ◦ ここを理解しておかないと非効率なクエリを発行してしまう、またそれの解決 手段がわからないなどが起きる • 複雑な集計はまだまだORMではカバーしきれないこともある
23. ORM • RDBとオブジェクト指向におけるインピーダンス・ミスマッチを解消する ◦ インピーダンス・ミスマッチ = データモデルの違いによるギャップ • ActiveRecordパターン ◦ RailsのActiveRecordは名前の通りActiveRecordパターンが元になってい る ◦ RDBのテーブルと1つのモデルを関連づける考え方 ◦ 例: Userクラスとusersテーブル • 注意: 1つのテーブルと1つのモデルを関連づけるのがORMではない ◦ 複数のテーブルを1つのモデルに関連づけるものもある • オブジェクトを通してSQLの実行やオブジェクトへのマッピング、DBのコネクショ ン管理なども行ったりもする
24. 演習: データベースのデータを画面に表示 • データベースはSQLiteを使用 ◦ データベースサーバーが不要な軽量のDBMS ◦ セットアップが簡単 ◦ PostgreSQLやMySQLと比較すると機能が貧弱 • ORMライブラリは使用しない ◦ 規模感的に不要 ◦ SQLの結果とオブジェクトのマッピングを感じて欲しい
25. 発展課題 • 個別のTodoを表示するページの実装 ◦ /todos/:id のルーティングをどうするか • Todoを保存するページの実装 ◦ フォームページの実装やPOST先のエンポイント • app.rbのリファクタリング ◦ 例えばControllerやModelのクラスを外に切り出す • フレームワークとしてもっと汎用的に作る
26. TypeScript
27. ゴール • TypeScriptに親しむ ◦ 特に普段動的言語で静的型付けの言語を触ったことない人達 ◦ とはいえ、今回は型に関しては大分ゆるっといきます • 非同期処理について理解する ◦ APIの呼び方 ◦ 非同期処理の実装方法 ▪ Day 3でも登場するので、今日頑張って理解してください
28. フロントとサーバーの分離 • Webフロントエンドが複雑になるにつれ、フロントとサーバーが分離することが増 えてきた ◦ APIサーバーとそれを呼ぶクライアントアプリケーション ◦ MVCのVが複雑化・独立してきたとも言える • jQueryだけでは戦えない世界
29. JavaScriptとTypeScript • 以前よりマシとは言え、複雑なクライアントサイドアプリケーションを実装するに はJavaScriptの言語機能では厳しいことも多い • TypeScriptはJavaScriptに静的な型機能を提供するトランスパイラ ◦ 個人的には原則TypeScriptを導入するのがオススメ ◦ 型機能をフル活用しないにしてもTypeScriptの方がJavaScriptより厳格
30. 環境構築 • Visual Studio Codeのインストール ◦ フォーマッターのPrettierも入れる • Node.jsのインストール ◦ マシンにnodebrewが入っているはずなのでそれを使う
31. Visual Studio Code • TypeScriptを書くにあたってコード補 完や型定義の参照などで便利 • とりあえず覚えてほしいショートカット ◦ ファイル検索 cmd+p ◦ コマンドパレット cmd+shift+p ◦ ターミナル ctrl+shift+` ◦ 定義へジャンプ F12
32. TypeScirptのコンパイル • tsc --init ◦ TypeScriptのコンパイル設定が生成される ◦ デフォルトから以下の3点を変更します ◦ noImplicitAnyをfalse ◦ outDirをdist ◦ includeに[“src/**/*”] • tsc ◦ TypeScriptをJavaScriptへコンパイルします
33. noImplicitAnyについて • 型定義がない変数はany型(つまり何でもいい)になる • noImplicitAnyがtrueだと暗黙のany型が許容されなくなる • 今回falseにした理由 ◦ 型をつけるということになれていないと結構しんどい ◦ falseでも十分にTypeScriptの恩恵を得られる
34. 演習: TypeScriptをコンパイルする • 演習資料 Section 1を参考に環境構築、TypeScriptのコンパイルまでやろう
35. 基本文法: 変数
36. 基本文法: 関数
37. 基本文法: クラス
38. 基本的な型 • boolean • number • string • array • tple • any • void
39. 型推論 • 変数などの型を明示的に指定し なくても型システムの方で推測 し、型を決定してくれる仕組み ◦ 推測できない場合、anyや neverなどになる
40. 演習: TypeScriptに慣れる • 演習資料 Section2を写経してみよう • 他にも以下のことを試してみよう ◦ 型と違う値を入れようとしたらどうなるか ◦ 複数の型の要素を1つの配列にいれたらどういう型に推論されるか ◦ dist以下の生成されたJSとsrcのTSを比較してみよう
41. DOMとDOM API • HTMLをツリー構造として表現、操作すること ができるAPIとその仕様 • HTMLを変更して画面を書き換えることが多 かったJSとは関係が深い • DOM APIの例 ◦ getElementById ◦ createElement ◦ addEventListener
42. イベント • Webフロントエンドでは画面上やプログラム内で起きたイベントをトリガーに処 理を実行したいことが多い • イベントの例 ◦ HTMLの読み込みが終わった ◦ ボタンがクリックされた ◦ ユーザーがキーボードのキーを押した
43. addEventListener • ある要素に対して特定のイベントが起きたときの処理をコールバック関数で指 定する • ちなみにaddEventListenerに限らず、関数に別のコールバック関数を渡すの は頻出
44. 演習: DOM APIを使ってみる • HTMLファイルを用意し、コンパイルして生成されたJSを読み込む • HTML上のボタンがクリックされたらbodyタグに新しくdivタグが追加されるよう にする
45. 非同期処理 • 応答に時間がかかる処理などを行う際に は非同期処理をすることが多い ◦ Web APIの呼び出し、ファイルアップ ロード、ファイルシステムへのアクセ ス • 同期的に処理をすると応答を待つ間プロ グラムの実行がブロックされるなど、ユー ザーの体験を損う
46. 非同期処理の方法 • コールバック • Promise • Async Function(async/await) • 上記3つそれぞれについてWeb APIを叩くコードを書きながら学習していきま す
47. httpモジュール • Node.jsの標準モジュールの1つ ◦ 若干低レベルなインターフェースなのであまり使い勝手はよくない • HTTPサーバーやクライアントとしての機能を提供
48. APIサーバー • Sinatraで簡単なAPIサーバーを用意 • エンドポイントは以下の2つのみ ◦ /users ◦ /users/:id/todos
49. 演習: httpモジュールでAPIを呼ぶ • Section 4、5の2つをやってください • 細かい構文のことよりhttp.getの第2引数のコールバック関数に着目してくださ い
50. 非同期処理のネストは辛い • ある非同期処理を完了したら更に別の非同期処理を行いたい時はままある • 今回は2段階のネストだけどこれが3段階、4段階だったら…?
51. Promise • Promiseとは非同期処理を抽象化しオブジェクトとして扱えるようにしたもの ◦ 厳密に言うとPromiseという非同期処理のデザインパターンをJSに組み 込んだもの • Promiseの導入により、非同期処理のインターフェースを統一できる ◦ コールバック関数の場合、コールバック関数の引数が使用などで決まっ ているわけではない
52. Promise(2)
53. 演習: Promiseでコードを書き直してみよう • Section 6のコードを書いて実行してみよう • 今回はAPIがエラーを吐いたときの対応も入れてあります ◦ rejectの感じを掴んで欲しい
54. Fetch API • XMLHTtpRequestの代わりとなる非同期通信のためのAPI ◦ IE対応が必要の場合はPolyfillが必要 • Node.jsも対応していないのでNode.js環境ではnode-fetchモジュールが必要 ◦ 今回はnode-fetchモジュールが必要 • fetchはPromiseのインスタンスを返すので、そのままthen/catchなどが使え る ◦ httpの場合、Promiseインスタンスを自分で作る必要があった
55. 演習: Fetch APIを使う • Section 7のコードを書いて実行してみよう ◦ httpをPromiseでラップしてた時にくらべて大分ラクなはず
56. Async Function(async/await) • Async Functionは非同期処理を行うための関数を定義する構文 • 現在でもっともモダンな書き方 • Async Functionとして定義された関数は必ずPromiseのインスタンスを返す ◦ つまり構文が違うだけで中身的にはPromiseなのでPromiseの理解が重要
57. 演習: Async Functionで書いてみる • Section 8をやってみる • asyncと関数定義に書かれているのがPromiseを返す関数 ◦ つまり非同期に実行される • awaitを付けて呼ぶとそこで非同期処理の完了を待つ