sandonemaki / my_read_memo

あなたにとって大切な一冊を見つける読書アプリのリポジトリ

yondeco「自分にとってどのぐらい大切な一冊」なのか、「見える化」するアプリ

サービス概要

yondecoアプリは、いま読んでいる本が自分にとってどのぐらい大切な本なのか、見える化できる読書アプリです。
アプリの機能に沿って読書メモをとることで、書評家のように自分だけの本のレビューが完成していきます。
詳細は 🔗トップページ をご確認ください。

▼ yondecoアプリの取扱読書範囲

▼ サービスURL

https://yondeco.site

レスポンシブ対応済のため、PCでもスマートフォンでも快適にご利用いただけます。

▼ 紹介記事(はてなブログ)

いま読んでいる本が「自分にとってどのぐらい大切な一冊」なのか、「見える化」するアプリを作りながら考えたこと
開発背景や、サービスのリリースまでに勉強したことなどをまとめています。
初学者の私が開発を通じて、さまざまな技術的な選択や学習のアプローチを経験してきたので、その経験と学びを共有し、今後の展望についても触れています。

▼ 上記ブログのサマリー

サービスの概要
アプリの対象ユーザー、アプリを作ろうと思った背景

機能仕様
アプリの機能仕様、画面設計、キャラクターを作成しました。

ユーザー体験設計書
サービスの定義、ターゲット、課題、ユーザーの感情ゴールや機能ゴール、ユーザーの問題を解決する機能一覧を作成しました。

詳細体験設計書
上記ユーザー体験設計に基づきユーザーストーリーを作成しました。

機能一覧
上記詳細体験設計書に基づきユーザーをゴールに導くために必要な機能一覧を作成しました。

技術詳細
使用技術、バックエンド、フロントエンド、インフラの技術的工夫を書きました。あえて ActiveStrage や miniMagic などの Gem を使わずにアップロード機能を作成した理由、 Vanilla.js を採用した理由、選択したアーキテクトについて書いています。

学習の工夫
学習方法を工夫することもエンジニアに必要なスキルと考え、さまざまな工夫をしながら学習を進めてきました。

▼ 使用技術一覧

その他お世話になったツール・サービスなど
Swiper、Panzoom、ImageMagick、Makefile

▼ インフラ構成図

▼ アーキテクト

▼ ER図

▼ 画面構成図

my_read_memo's Issues

スキルの経過をテーブルにする

読書状況の判定結果をpopupでお知らせする

目的

読書状況の判定結果をpopupでお知らせする

なぜするのか

このアプリは、利用者に本の状態（乱読/精読/通読）を知らせることができる。
読書の状況は、読む総ページ数や、乱読画像メモの未読や既読の数によって、読書の状態が変わる。
具体的には、

• 読む総ページ数に対する乱読画像のメモが1/8未満の場合：乱読
• 読む総ページ数に対する未読の乱読画像のメモが1/8以上、1/4未満の場合：精読
• 読む総ページ数に対する未読の乱読画像のメモが1/4以上の場合：通読

利用者によってメモの既読のボタンが押される度に、読書状況の判定をする（実装済み）。
読書の状態が変わったら利用者にpopupにて本の状態をお知らせする。
それにより、利用者は乱読を続けるべきか、精読に進むべきか判断することができる。

関連するプルリク

• #43

---

やること

読書の状況が変わったらpopupにて本の状態をお知らせする。
具体的には以下のような文言を乱読/精読/通読ごとにpopupでお知らせする。
JSでコードを書く。
文言は乱読/精読/通読がわかるようにして、以下のものをダミーとして入れておく。

Congratulations!（精読）
ついに乱読フェーズをクリアしました！
まだ読んでいないメモがありましたら一読してから精読メモに進むことをおすすめします！
次に進むボタン

popupを表示するページ

popupの表示イメージ

やらないこと

cssを使ったデザイン。
デザインする時間は別途設ける。しかし最低限の形づくりは必要。

17th_本に紐づく乱読画像を読むためのモーダルに表示するためのロジックを書く

本の詳細ページにある乱読画像をクリックするとモーダルが開いて乱読画像を読むことができる
全体の位置付け

実装イメージ

• モーダルに表示するデータと表示に必要なテーブル情報
  
• ChromeとRailsとのやりとりの実装イメージ
• RailsとDBとのやりとりの実装イメージ

4th_本を登録して複数枚の乱読画像を投稿し、本の詳細画面に画像を表示させる

機能

• 本を登録する
• 複数枚の乱読画像を投稿する
• アプリの利用者はスマホから画像の投稿をすることが多い。
  • HEICを投稿された場合は使いやすいjpgに変換する
  • 変換にはImageMagickを仕様する

実装イメージ

• 実装が複雑なため事前に実装手順を作成した。

技術調査

• ImageMagickについて調査

見積もり

• 最小見積もり（日単位）
  • 4
• 最大見積もり（日単位）
  • 6
• 実際にかかった時間（日単位）
  • 5
• 時間がかかった要因
  • Heic画像が利用できる状態にするため、ImageMagickのインストールでつまづいた
  • コンパイル、Make に対する知識が浅かった

---

１周のざっくりとした流れ

1. やることを決める
2. 調査・実装
3. デプロイ
4. 誰かに言う・使ってもらう・使ってみる
5. 4ありきで、全体俯瞰・設計見直し（draw.ioだったり、スプシ）
6. 設計修正

---

デプロイの度にアプリを触ってもらっています
平日：毎週月曜日と木曜日の朝 8～10時 Discord
休日：月に1回で土曜日（たまに日曜日）10〜19時 Discord

D_仕事仲間の編集さんにテキストの依頼をする

編集さんにアプリのコンセプトや対象像、お願いしたいことをお送りする

• お送りしたもの
  • https://peat-ounce-20c.notion.site/96c57eda14874090bfcc7e41da7fd30a?pvs=4

私が今後やること（編集さんに関わる部分は2日で終える）

• アプリのコンセプトを作成してお伝えする
• アプリの対象像をお伝えする
• アプリでできることをお伝えする
• サイトマップとURLをお送りする
• トップページの構成作成してライティングをお願いする
• 各ページでライティングをお願いしたい部分をお伝えする
• 納期の相談をする

---

• 以下は編集さんが関わらなくても良い部分
• イラストレータを決める
• イラストレーターに依頼する
• 配色など表層の部分のデザインを整える（大きな配置換えはありません）
• 残りの機能の作成（1-2weekで完了）

本の表紙の投稿をheic対応にする

• #127

14th_searchページに掲載する用にメモの絞り込みできるようにする。

絞り込み内容

絞り込み条件

• 乱読メモに関する絞り込み
  • 本の核となる時代
  • 著者のプロフィール
  • 気持ちが高まったメモ
• 精読メモに関する絞り込み
  • 著者の意見
  • 引用された事実
  • 要約

最近のアクセス順

• 最近の乱読メモ
• 最近の精読メモ

---

全体のメモから絞り込む理由

• 個別の本に関する絞り込みではなく全体のメモによる絞り込みをする
• １冊の本に関して絞り込みが必要なくらい大量のメモが発生するケースは少ないが、今まで読んだ本の中から、絞り込み検索をすることで本から自分の感情や意見によって自分自身を理解できる方が利用者にとって価値が高い

10th_乱読メモ、精読メモの新規作成〜保存、保存内容を確認できる一覧ページを作成する

機能について

タブ切り替えで３つのメモを「行き来」する

アウトプットに値するメモを仕上げていくために以下の３つを行き来しながら仕上げていくことが大切なため、わざわざ利用者に遷移させない。

• 乱読画像（利用者が気になった部分をパシャパシャ写真に収めたメモ）
• 乱読メモ（画像では取れないメモ）
• 精読メモ（発散する乱読に対して、将来的なアウトプットにつながる収束的なメモ）

---

メモの種類を選択出来るようにする

📝 乱読メモ

1-2は、初期段階でアウトプットしておくと内容が入ってきやすいものを選んだ
3は、絞り込み検索によって自分の気持ちが高まった部分だけを集めることができる

乱読メモの種類
1 本の核となる時代と地域
2 著者のプロフィール要約
3 気持ちが高まったのはいつですか？ それはなぜですか？
4 その他

📝 精読メモ

1-4は精読メモにおいて必須の内容。
noteなどの記事へのアウトプットを見据えた段階では、収束させることが必要なので、
1-3の著者に関するメモ、4の自分の意見が大事になる。

乱読メモの種類
1 要約
2 著者の意見
3 引用された事実
4 自分の意見
5 その他

---

カウント機能

• 乱読画像
  • 乱読画像は少しでも気になったページのメモ。
  • 数が多いほど自分にとって大事な本（精読するに値する）かどうかが決まる
  • そのため、総合計枚数、未読のメモ数、精読フェーズへの基準枚数をカウントする
• 精読メモ
  • アウトプットするためには、著者の意見だけでなく自分の意見の数がある程度必要
  • そのため、自分の意見の数をカウントする

5th_2　投稿した画像の未読・既読のカウントを表示

投稿した乱読画像の未読・既読の状態をカウントする

なぜやるか

• 目的：
  • 乱読から精読に進んでいいかの評価に使用する
    • 乱読から精読への評価は、読む予定のページに全て目を通した上で、読むページ数に対してメモが1/8以上1/4以下が精読状態になる
    • 利用者が状態を把握するため
• 手法：
  • Randoku_imgクラスの状態をActiveRecordのgroupを使用してカウント
• 要件：
  • 投稿可能な画像が全てカウントされること
  • デフォルトは未読であること

11th_ペーパープロトタイプを作成

なぜやるか

8thのフィードバックでペーパープロトタイプが必要なことがわかった。

作る理由

• ユーザー視点での質の良いフィードバックをもらうため
• 全体イメージを掴んでもらった上で設計に対するフィードバックをもらうため

12th_トップページ_本の一覧を作成

乱読・精読アプリにおけるトップページの役割

このアプリは、乱読から精読までをサポートするアプリです

• 乱読：
  • 発散。引き出しを増やす効果読書。精読に値する本を見つける効果がある。
• 乱読メモの取り方：
  • 少しでも気になった部分を写真にとっていく
• 精読：
  • 収束。将来的なアウトプットに向けた読書
• 精読メモの取り方：
  • 要約、著者の意見、自分の意見をメモしていく。

---

トップページの役割と必要な機能

アプリの評価軸

• 乱読画像メモの数が多いほど、自分にとって大切な本。
• 精読メモの数が多いほど、アウトプットに向かえている状態。

上記評価のためトップページでは以下を表示する

• 乱読中の本、精読中の本、通読が必要な本（乱読に含まれる）。
• 乱読画像の数、乱読メモの数、精読メモの数。
• 利用者の現在地がわかるため、乱読画像枚数、登録本数、精読フェーズの本の数。
• 前回学習した本（メモの再読、投稿）

Sort機能について

乱読中の本

• 乱読画像メモの多い順
• 乱読画像メモの投稿順
• 登録した本の順
  • メモが一枚も投稿されていない本もあるため必要
• 乱読 or 通読フェーズ
  • 通読は気になるページがあまりに多すぎて消化できていない状態

精読中の本

• 精読メモの多い順
• 精読メモの投稿順
• 登録した本の順

イラストレーターさんと打ち合わせ

打ち合わせでやること：

• 全体コンセプトの説明
• サイトマップの説明
• どのようなイラストを描いて欲しいかをなるべく具体的に伝える。
• 提案して欲しい部分を伝える
• 進め方を決める
• 納期を決める

事前にお送りしているドキュメントを見ながら説明をする

• https://peat-ounce-20c.notion.site/fcaa2af8833d45f784b52abda999cc9f?pvs=4

7th_本の一覧を作成する

機能の説明

役割：トップページ。
登録している本や資料の一覧が見れる。
以下を表示させたい。

• 本のタイトル（登録順）
• 著者名
• （乱読）メモの数
• 乱読・精読状態
• 本の登録ボタン

7th でやらないこと

• 登録 / 更新 / メモの数で sort できるようにする。
• 本・メモの検索機能

なぜこの機能が必要か

• 利用者がメモをとった本の一覧を見れるようにしたいため。
• また利用者にとって大事な本（精読すべき本）は何なのかをわかるようにしたいため。

画面設計

• かんたんな画面設計、ブラウザとRails、RailsとDBとのやりとりの手順はこちら

学んだこと

7thの学び

ログイン前のTopページを作成（使い方やコンセプトを表記）

編集と進めているテキスト
https://docs.google.com/document/d/14ECyAmoOH8arYCqzCA2t93Tt34keRh65uRIhLIwCpKA/edit?usp=sharing

テキストを依頼する時の説明に使用したもの

• 全体のコンセプト
• サイトマップとトップページ

---

イラストはやや修正はあるが完了済み

• イラストレーターへの説明資料

popupが期待通りのタイミングで動くか確認。期待通りでなければ修正

popupの動作確認をしていた時に違和感がある部分が見つかったので以下を修正する

修正1

「精読突破」は「精読基準突破（乱読メモを読んで精読に進もう）」に変更する

理由：一枚もメモを読んでいない場合は精読突破ではなく、精読の基準を突破しているだけなので言葉を変更する

---

修正2

通読 popup

精読になった時はpopupが出てくる。
しかし、通読に向かうものが出てこない。
controllerからのレスポンスが出ているか、jsでレスポンスをうまく扱えていないかどちらかが問題
多分後者だとは思う

やらないこと

画像の削除ができたら、乱読popupが出るかの確認が必要
最優先事項ではないので今はやらない。

2nd

9th_大改造という名のリファクタリング

なぜやるか

7thでメソッド分けをしたが、それによってコードが読み辛くなってしまった。
今までのルールでは収まりきらないため、新たなルールを追加して初めての Rails リファクタリングをする。

新旧合体ルール

view_model：

• 変わらず view から変数を参照する変数を initialize する場所
• 表示するための簡単な計算ロジックを model 側に置いていたが、view_model に置くことにした。
• module 名、class 名に view_model をつけていたが、クラス名は model 名と同じにした。
• 一旦 view_model を太らせて後で考える。

model：

• ARの多機能性を考え、model にはロジックを置かないことにした。
• 表示するため以外のロジックは controller にロジックを置く

controller：

• 不必要なメソッドを削除。メソッド以外の解決法を考える。
• メソッド化する場合は、責務をシンプルにする
• ロジックを controller に置く
• なるべくシンプルな組み込みメソッドで実装する
• チェーンメソッドを使うことで型の情報や状態がわかり辛くなる場合はコメントアウトする。

view：

• @ を使わない。view_model のメソッドを参照する

CIを回すためdatabase.ymlのtestモードのhostをlocalhostにする

関係するファイル

• database.yml
• .github/workflows/cicd.yml

デフォルトはdockerでの作業のためhostをmy_read_memo_dbにしている。

ciを回すために、database.yml の test モードに値が localhost の 環境変数 HOST DB を追加。
値は cicd.yml にて代入

同時にdockerでpostgres13イメージを使用しているためイメージに変更する。

• postgresイメージに変更
• 環境変数を修正

D_ロゴを作成する

yondeco.siteのロゴマーク案を４案作成した
お仕事ならロゴマークの意味や世界観をもっと考えるけれど、今回は以下の条件があっていれば良いと思った。
左から３案が気に入っている
はめてみて決める

ロゴの条件

• ロゴマークの隣にyondecoが来てもおかしく見えないこと
• 雰囲気が柔らかめであること
• キャラクターと合わせても違和感がないこと

D_イラストレーターを決めて依頼をする

イラストレーターを8人選定した
ここから一人に絞ってお願いをする
https://peat-ounce-20c.notion.site/yondeco-eb577578430f4dcb9d0a2f389f8450b7?pvs=4

以下はイラストを選ぶ時の基準
雑誌：ストーリー性あるイラスト、昔だとカットイラスト。
書籍：小説の雰囲気を出しつつも、結果とは距離があって想像させるイラスト。
映画：直接的でありつつも先が気になる感じのイラスト。
漫画：直接的かつ個人的なイラスト。
Line：日常的に使えるイラスト。ギャグ性、仕草や表情が豊か、キャラクター性がある。
コーポレート：まじめ、動物キャラクター、ゆるくない、シンプル、近い未来への期待

今回は今までの雑誌や書籍、コーポレートの選び方と違い、Lineや漫画のイラストレーターの選定に近い感じで選んだ。

画像のアップロード処理をメソッド分けする

現在は一つのアクションに生のRubyで複数の処理を埋め込んでいる。
できるだけ依存関係の少ない、シンプルな責務のメソッドにしたい。

1st

アプリのキャラクターを考える

全て賢い動物から探した。
こちらにも記載：https://peat-ounce-20c.notion.site/fcaa2af8833d45f784b52abda999cc9f?pvs=4
イラストレーターさんのアイデアが出たら一緒にして決める

『賢い動物の性質からイメージ』

• 乱読：たこ
  多数の足、多数の脳、タコの知性という本もある

• 精読：フクロウ
  いわずもがな知性のイメージ

• 通読：リス
  口に食べ物を入れて溜めておくのが、読まずに溜めておく通読のイメージ
  ちなみに貯めた食べ物を腐らせてしまうこともあるそうです

---

『かしこい動物の名前からイメージ』

• 乱読：しろいるか（読んでこ）
  しろいるかはおでこが特徴

• 精読：パンダ（読んだ）or ねこ（読むにゃ）
  過去形なので精読にあてがった。ねこそのままでも良い

• 通読：ぞう（読むぞう）
  消去法で通読になった

---

『哲学者シリーズ』

髪型とか髭とか真似してもいいのかなと。わかり辛いかも？？

• 乱読：ニーチェ（ニャーチェ）
  親しんでいる人が多いので乱読のイメージ

• 精読：ソクラテス（ニャクラテス）
  いわずもがな知の頂点

• 通読：デカルト（ニャカルト）

行動設計書、コンセプト、仮設キャンパスを明記する

Vite-Railsを使えるようにする

• webpackerを剥がす
• jsとcssを反映できるようにする

ec2ではproductionでrailsサーバーを立ち上げるようスクリプトを修正

• 手動でprocuctionモードでbundle exec -b 0.0.0.0 rails s -e productionで立ち上げれるように設定
• 手順をメモ
• EC2への自動デプロイはすべてproductionモードにする

投稿した本の画像を保存して表示できるようにする

D_デフォルトの本の画像をデザインする

イラストレーターさんに、『自分ひとりの部屋』の表紙のパロディイラストを描いてもらうことにした。
上記表紙は、ウルフが考え事をしている写真。

---

ヴァージニア・ウルフ（Virginia Woolf、1882年1月25日 - 1941年3月28日）は、イギリスの小説家、評論家、書籍の出版元であり、20世紀モダニズム文学の主要な作家の一人。両大戦戦間期、ウルフはロンドン文学界の重要な人物であり、ブルームズベリー・グループの一員であった。代表作に『ダロウェイ夫人』（1925年）、『灯台へ』（1927年）、『オーランドー』（1928年）、『波』（1931年）などの小説や「女性が小説を書こうとするなら、お金と自分だけの部屋を持たなければならない」という主張で知られる評論『自分だけの部屋』などがある。

---

「女性が小説を書こうとするなら、お金と自分だけの部屋を持たなければならない」という主張で知られる評論『自分ひとりの部屋』の表紙は、ウルフが考え事をしている。
自分の世界を作るために考え事をすることは、「自分にとって大事な本を見つけてアウトプットする」を援助するyondecoアプリの大事にする価値観に近い。

Auth0でログイン機能を作成する（userテーブルも一緒に作成する）

関連するプルリク

• #134

テストはuserに紐づいていない段階のもの。
それゆえにCIが落ちてしまう。
一通り、userに紐づく情報を表示したらテストを書きます

EC2のipをElastic IPに変更したのでCDの設定でipアドレスを変更する

Github ActionsのSecretとMakerfileで使っている環境変数の値を変更した

6th_使い手にわかりやすい名前づけとファイル構成を考える

なぜやるか

• 目的：controllerからそれぞれのクラスのメソッドを呼び出すことでDRY化したい
• 要件：
  • 以下の本と記事を読んで、名前付け、メソッド分け、コメントの付け方に関するルールを取得する
    • WEB+DB PRESS 名前付け大全
    • 定番のコード規約とライブラリから学ぶJavaScriptの命名テクニック（初級編・応用編）
    • リーダブルコード
  • 名前の付け方、メソッド分け、コメントの付け方を意識してコードを書く

ああああ

ふぇふぇ

• #32 もーだるを作成する

3rd

15th_検索の技術選定【Meilisearch】

メモの検索をどういう方法で検索するかを調べた。
ActiveRecord の ORM で検索は可能だが、もう少しリッチな検索ができないかと考え、他にもどのような方法があるかを調べた。

検索方法の候補

1. 毎回データベースに問い合わせる
2. Elasticsearch
3. Algolia
4. Meilisearch

16th_Meilisearch の技術検証

• Meilisearchの技術検証ノート
• Meilisearch の Ruby 検証用リポジトリ
• Meilisearch の Rails 検証用リポジトリ

ec2でnginxのdockerを試す（ドメインがローカルと違うため本番用ドメインで試す）

関連するプルリク

• #122

---

https://zenn.dev/oreilly_ota/articles/22584de7f839bd
上記を見本に、本番環境用のdocker-compose.prod.ymlを作成する
上記ファイルのコンテナ実行コマンド
$ docker-compose -f docker-compose.prod.yml up

vagrantではドメインがlocalhost.yondeco.site
ec2ではドメインがyondeco.siteなので、docker用のnginxの設定も変更して試す
ec2ではdockerでもproductionモードでrails sする

13th_URIを作成した

乱読・精読webアプリの URI

作成中に混乱することが多かった。
ペーパープロトタイプを作成したために自作 Web アプリに対する解像度が上がったので、URI を作成しようと思った。
生成のための収集、保存、確認を意識したURIを作成した。

pracA

本の状態が一度も精読になっていない場合は、精読メモのタブに鍵をかける（disabled）

• 鍵の位置を精読メモの左端に変更
• 鍵がある場合は、タブをクリックできないようにする
• 鍵がある場合は、文字と鍵の色を薄くする

D_全体の色、余白、フォントサイズを調整

ログイン後のcssはpc/sp版全て調整・修正する。

フィードバックを記入するスプレッドシートを作成する

• デプロイの度、月木の朝のもくもく会で触ってもらい、フィードバックをもらっている。
• 現在細かいフィードバックは scarapbox にまとめている
• フィードバックの中には「いつかやる」に回したい修正項目もあるので、一覧で見れるスプレッドシートにまとめておく。
• 現在はエンジニアで限られた人に触ってもらうことが多いが、もう少し大枠が出来てきたら他の人にも触ってもらいたい。

docker-compose.prod.ymlに書いている処理をproduction用のDockerfileを作成して移動させる

開発と本番でDockerfileを一緒にしていたが、わけることにした。
理由は、本番環境用のdocker-composeの処理をできるだけ軽くしたいため

bundle installやプリコンパイルなどを本番用のDockerfileに書く

テストの考え方や構文を学びつつテストの追加

• 機能に対してテストが薄いので追加する
• 表示するドメイン用語が変更になった部分は変数名も変更したい。
• 一度に全部変更する方が早いが、テスト->リファクタの勉強にならないので、遅くなってでも、テスト->リファクタをやっていく
• 必要があれば、テスト前に手元でディシジョンテーブルを書く
• テストが書き辛い部分はコードの修正もする
• 1人でできない場合はペアプロをお願いする

メモの検索結果で0番を選ぶとエラーが出る

エラーの内容

別の検索結果遷移した後に、メモの種類で検索する を選ぶと以下の nilエラー になる

対策

メモの種類で検索するを選んだ時は、Js 側で event の preventDefault() 、
home_controller 側でmemo_search_path に遷移させる

---

エラー：

NoMethodError in HomeController#memo_search_result
undefined method `count' for nil:NilClass
Extracted source (around line #34):
     
        end

      @selected_memos_count = selected_memos.count || 0
      @selected_memos =
        if selected_memos.present?
          selected_memos.map { |memo|

Parameters:

{"authenticity_token"=>"[FILTERED]", "selected_search_value"=>["0"]}

JSでモーダルを作成する

なぜやるか

スライドの目的

このアプリは、乱読中に気になったページの写真（乱読画像）をメモとして残せるアプリです。
クリックした乱読画像を拡大して、再読することで自分がなぜそのページが気になったのかを振り返えれるようにするため。クリックした乱読画像の前後の画像も読めるようにしたい。

実験について

ポートフォリオ作成の手を止めて、JSの学習をしてきたが、アプリ内でJSを使うのが初めてのため。
アプリの外で練習することで技術は上達するかもしれないがアプリと向き合う時間が減るためアプリ内部で実験することにした。

実験におけるスライドの要件

• サムネイル画像をクリックすると拡大表示
• 左右のボタンで乱読画像を行き来する
• 画像に紐づくページネーションを追加
• 画像に紐づく画像名を追加
• 画像に紐づく保存日を追加

#32

トップページに本の詳細ページへのリンクを貼る

ref：randoku_imgsテーブルのカラムreading_stateを変更する

概要

booksテーブルのカラム名「reading_state」とrandoku_imgsテーブルのカラム名「reading_state」がかぶっているため、
randoku_imgsテーブルのカラム名を「is_already_read」 0/1のbooleanに変更する
今後必ずカラムを一意にしたいわけではない。
今回に関しては別にすることで検索上のメリットが大きいため変更することにする。

詳細

grep検索でreading_stateメソッドが使われている箇所を調べると、カラム名の被りがあった。
Bookの乱読/既読/精読を表現するカラム名が「reading_state」
Book.randoku_imgsの未読/既読を表現するカラム名が「reading_state」

booksテーブル

create_table "books", force: :cascade do |t|
  t.integer "reading_state", default: 0, null: false
end

randoku_imgsテーブル

create_table "randoku_imgs", force: :cascade do |t|
  t.integer "reading_state", default: 0, null: false
end

変更内容

• 一時変数名「reading_state」を適正なものに変更
• それ以外に内容に沿っていない一時変数名があれば変更する
• randoku_imgsの未読/既読を表現するカラム名を「is_already_read」 0/1のbooleanに変更する

grepで見つかった変更予定のrandoku_imgsの「reading_satate」メソッド

app/controllers/books_controller.rb:72:          
book.randoku_imgs.find_by(id: img_id).reading_state = reading_id

app/modules/reading_state.rb:7:    
@randoku_imgs = book.randoku_imgs.group('reading_state').size

app/view_models/view_model/books_new.rb:26:      
reading_state = book.randoku_imgs.group('reading_state').size

5th_1_乱読画像を投稿した後にサムネイルを表示

投稿した画像のサムネイルを表示

なぜやるか

• 目的：
  • 投稿した乱読画像は文字を読める必要があるためサイズを縮小しない。
  • 表示にそのままのサイズを掲載するとパフォーマンスが悪いので画像を読む以外の目的ではサムネイルを表示する。
• 手法：
  • ImageMagick を使用。学習のためにGemを使用する。
• 要件：
  • 複数枚の画像を投稿した際に、サムネイルが表示される
  • jpg、jpeg、HEIC、png、スクリーンショット、pdfを投稿した際のサムネイル化を可能にする
  • 本画像の Exif 情報を削除してサムネイル化する
  • 画像の更新順で並べる
• やらないこと：
  • サムネイルサイズの調整

swiperを使うための準備

• CDNとNPMを試す。
  できればcdnが良いが、vite-railsがCDNを使えるかわからない

• 実験用routeの作成

• JSを使うための準備

8th_本の一覧をカイゼンする

7thを勧めても要件を満たさないため、8thでむきなおりをする。
#7 (comment)

下のTOP画面の本の一覧画面から、掲載情報を変更することにした。

なぜやるか

• 目的：ユーザーの目的が自分にとって大事な本を理解してメモを読み返すこと。
• 下の画面では情報整理ができていないためユーザーが混乱し、行動に移すことが少なそうだと判断した。そのため表示内容を変更する。

現在の画面

これまでの要件

• 目的： 自分にとって大事な本（精読すべき本）をぱっと見て理解できるようにしたい
• どの本が乱読・精読状態にあるかをぱっと見てわかるようにする

制作物の問題点

• 現在の本の一覧画面からはメモ内容を把握することができない -> メモ内容を思い出せない
• 要件に対して必要以上の情報があり混乱を招く。

追加の要件

• 目的：ユーザーの目的が自分にとって大事な本を理解してメモを読み返すこと。
• 遷移せずに利用者がどんなメモを取ったかがぱっと見てわかるようにしたい

解決策

• インスタグラムのように、最新の乱読画像を数枚（3-4枚）見れるようにする。
  

• SCRAPBOXのように、メモの内容を見える化する
  

• 以下の情報は要件に必要ないため削除する

  • 読む予定のページ数、入力メモ数

• 乱読の状態が0となって表示されているので修正する

機能としてのゴール

大枠を作るフェーズのため、写真と必要ネームが表示されていればOK

やらないこと

• 表紙を本のアイコンとして表示
• 登録 / 更新 / メモの数で sort できるようにする。
• 本・メモの検索機能

Originally posted by @sandonemaki in #7 (comment)