RailsTutorialをやり始めてから１年後にサービス公開まで辿り着きました
2019年の7月下旬からRailsTutorialをやり始めました。RailsTutorialは14章までありますが、おおよそ2～4日で1章をやるくらいのペースで進めていましたから、およそ2か月くらいをかけて終わらせました。
その後、自分なりのサービスを1本書いてみようと思いいたり、つい先日（2020年8月2日）に、公開することができました。
このノートでは、Tutorial後にやったことを振り返ってみようと思います。個別に加筆することもあるかもしれませんが、まずは書き出しを優先で書きます。
作図ツール
まずはどこから手をつけるにしても、画面イメージの作成が必要だと感じました。実務ではVisioで作図をやったことがありますが、個人ではお高いので諦めました。最悪Excelでもよいかと思いましたが、せっかくなのでPencilというものを使ってやってみました。
Pencilの作図画面はこんな感じです。
使用感
直感的に画面コンポーネントを配置できました。画面コンポーネントの部分をダブルクリックすると中のテキストを編集できたりしたので、実務で画面設計をするときにもこれは使えるんじゃないかなと思いました。
個人的に一番良かったところは、「表」も直感的にかけることです。
テキストと矢印の作図も簡単でした。矢印とつなげられる「辺」もExcelだと上下左右の4か所くらいしかありませんが、Pencilだとどこにつなげてもよいところが個人的に刺さりました。
作るサービス
自分自身の経験から、工数報告をするサービスを作ってみることにしました。自分自身の経験から作るサービスを決めるというのは、「こういうものがあればいいなぁ…」と思っているもののほうが、設計が容易だからです。
最初にバージョンを作った後も、機能を育てていけそうなものを選んだつもりです。
画面イメージの作成
Pencilを使って画面イメージを作成しました。この時に意識したことは、「テーブル定義」をアウトプットに書くために必要なものを書き出すということです。実務で納品物に場合にはもう少し丁寧に書いたほうがいいと思いますが、インデントが少々粗くても今はいいかなと思います。
どうしてこうしたんだっけ？という疑問は、数日後の自分に浮かんが来るので、思うところは適宜書き込んでいます。
この時はやっていませんでしたが、「その画面の初期表示時主要なパラメータ」については、画面イメージの作成時点で書き出しておいたほうがいいと思いました。
初期表示時以外（＝例えば検索ボタンを押した後等）は、画面にある情報と、初期表示時の情報を使うことになりますから、ある程度自明です。
対して初期表示時には、GETやPOSTなどのパラメータで渡される情報、セッションの情報くらいです。それらの情報から画面上に描画する情報を取得する必要があります。そういった状況に耐えられるテーブル定義をしなければならないので、画面イメージ時点で考え、書き残しておけると良いです。
最終的にはいろいろな文章を書くと思いますが、初期段階では後回しにするのでダミー文字で埋めて考えました。
ここも、中央揃えか左揃えかなども甘々で書くだけ書き出してます。
場合分け必要な時にはそのイメージとルールについて書いてみたりしました。
テーブル定義
下記のようなフォーマットでテーブル定義を作りました。
私が経験した過去のプロジェクトでよくあったのは、テーブルごとに１シートのExcelで作っているところが多かったです。しかし今回は、１表ですべてのテーブル＋カラムを管理することにしました。
同じ項目が別テーブルにあるかどうかも一覧で見れるので、この方式のほうがお気に入りになりました。
先に作成した画面イメージから、テーブル定義を作っていきました。
やろうと思えば、ユーザのIDに紐づく「２つ以上はない」情報は、全部ユーザテーブルに入れても制御はできますが、テーブルのくくりも意識して別テーブルに切り出したりもしています。
主キーはModelがIDを作ってくれるので、自動的に決まります。PK以外にユニークになるものがあればここで考えておきます。
また、データ特性を考えてIndexも貼っています。例えば未処理の件数は一定件数以内にとどまるので、処理済みフラグを未処理で検索する場合はIndexが期待できますし、勤怠情報のようなものはユーザIDと年月日で一定の件数に収まるのでIndexが期待できるので貼っています。
あとはこの表を見ながら、migrationファイルを作っていきました。
DFD（データフロー図）
テーブルの設計漏れなどがあるとつながらないところが出てくるので、データの流れ（主なインプットとアウトプット）を記載しています。
これはあくまでデータフローなので、画面遷移ではありません。従って、マル（＝画面）とマルをつないではいけません。画面遷移を整理したければまた別の資料ですね。
DFDが真価を発揮するのは、ある程度大きな範囲を見渡せるので、複数人で開発するときの意思統一に使ったり、間が開いた時の保守資料に使ったりにも使えますが、「統合テストのシナリオ」になることだと思っています。
例えば「工数入力」のテストでは、「ユーザ・工数設定」で登録した工数に対してのテスト、「工数表新規作成」で登録した工数に対してのテスト両方をやっておきたいですね。
他にも「ユーザ・工数設定」で「工数表実績」を削除した後、「工数報告照会はどうなっているか？も見に行きたいですね。
ライブラリの選定
ライブラリを選定します。今回のサービスの場合、１つだけこだわったのは、一括登録、一括更新をできるようにしたという点です。
工数報告をするにあたっては、１日ずつ入力する人もいますが、遅刻しない人の「開始時刻」は毎日定時ですし、休憩時間も毎日１時間です。残業がない人は「終了時刻」も毎日定時になるでしょう。
そういう人は月末に時間をかけずにコピー＆ペーストでやりたいので、Excelライクな入力ができるようなライブラリを探しました。
選び方
まず自分なりに要件をはっきりさせます。
・無料であること
・表形式で入力できること
・コピー＆ペーストで入力できること
・GPLライセンスは除外する（後々面倒なことになりたくない）
・商用利用可能なものであること（後々広告を載せる可能性があるなら）
そういったものを加味して選んだのは、Handsontableのver6です。
作って作って作りまくる
RailsTutorialのやったように、モデルを作ったり、ビューやコントローラを作って画面をどんどん作っていきました。
一度Tutorialをやっていますから、「これ、RailsTutorialでやったやつだ」となることが多いです。
開発初期では手元のプロジェクトにソースコードがないので、使いまわせそうなものがあれば自分で作ったRailsTutorialの時のSampleAppのプロジェクトから、ソースを流用してくるとよいです。
これまでに作った画面イメージ、テーブル定義、DFDなどを手元に置いてあとは作り続けました。
サービスの公開
RailsTutorialではHerokuでしたが、私の場合はVPSでサービス公開をしました。前提として、機能は拡充しながら育てていくつもりであったからです。Herokuの場合は無料バージョンではまずお話になりません。
また、有料バージョンだとしても、意外と割高です。それであれば、スペックをあげられる、かつAPサーバのリソースもDBのリソースもひっくるめて値段が調整できるVPSのほうがいいかなと思いました。
ここでも、サーバのセットアップ作業が必要になります。
いろいろな経験をしていくと、実務に向けて役に立ちますね。
この記事が気に入ったらサポートをしてみませんか？