やったこと メール認証成功後は、ログインをした状態でアプリに戻ってこれるように kaminariを使ったページネーションとデザイン logs/showページはとりあえず廃止の方向。コントローラでアクセス制限 indexに表示されるのは自分が作ったLogのみ 自分以外のユーザーのマイページにアクセスしようとすると、自分のマイページにリダイレクトするように navbarのデザインをラフ画のものに近づけるも、いざ見るとダサいので一旦取り消し ナビゲーションバー上のリンクをボタン化 Logasterでロゴを仮作成、ナビゲーションバーに置く ログイン時と非ログイン時でルーティングを変える indexのデザイン微調整 issueを追加 - YWTのログを限定共有する機能 - エラーページ - レベルアップの演出 要件定義の修正を提出（追加使用gem、Vue.jsを使わない方向への訂正など） わかったこと ログの限定共有機能について調べるも、有効な情報がない。今まではやりたいことに対しての解決策やヒントが検索すれば出てきたが、今回は無さそう。そうなると、自分の実装力が試されるが全く検討がつかない……情報の取捨選択がうまくなっただけで、実力はついてないのかも？と感じた Vue.jsで動的に絞り込み検索をしたかったが、そうするとデザインをやりなおすことになることに気づいた 検索したあとのviewはパーシャルで切り替えればいけそう？ ロゴをナビゲーションバーに置くだけでそれっぽい見た目になる 右寄せはmarginで実装できるときとできないときがある（カード要素のheader内に当てようと思ったがfloat-rightじゃないと駄目だった） 次やること 簡単なことから実装していく。エラーページとか 限定共有の実装方法に関して質問を投稿する herokuにデプロイして早めに見てもらう デザインに凝りすぎない（超重要） issueをどんどん建てるとやることが明確になって動きやすい

やったこと Logの確認画面のデザイン当て indexと同じような感じにした。カードは開いてる状態で見やすいように エラーメッセージの表示に関わるので辞書ファイルでいくつか日本語化 logとuserのバリデーション ended_on > started_onのバリデーション when_to_do > ended_onのバリデーション マイページのYWTカウント数がうまくいってなかったのを修正 プログレスバーの計算式修正 Google認証のときはメール確認をSkipするように あと何expの表示をプログレスバーの外に設置 学習時間の合計をマイページに表示 deviseのパスワード最低文字数を6→8 deviseのアラートに色付け わかったこと 子モデルのカラムについてバリデーションを追加する際の書き方で、 errors.add(Todo.human_attribute_name(:when_to_do), "は終了日以降の日付を選択してください") if ended_on > t.when_to_do Todo.human_attribute_name(:when_to_do)という書き方がポイント。そのまま:when_to_doは使えない（Logのモデルに書いてるので） かといって、log.todosを展開して、todos.when_to_doと書いてしまうと、カラム名ではなく日付がそのまま取得されてしまう。 t("activerecord.attributes.todo.when_to_do")じゃ駄目だった。 わかったこと、のtitleにpresence: trueを追加したかったけど、これがなかなかうまく行かない。 原因は、accepts_nested_attributes_forのreject_if: :all_blankで、これがあると、子モデルの中身がすべてblankだったら、削除してしまう。 やったこと、や次やることにはデフォルトでやった時間(worktime)や期限(when_to_do)が入ってるから、タイトルや詳細が空でも削除されることはないが、わかったことにはそのようなカラムがないので、どちらも空の状態となり、何も入力してない状態で送信ボタンを押すとわかったこと自体が削除されてバリデーションがかからない。 参考URL accepts_nested_attributes_for :knowledges, reject_if: proc{ |attributes| attributes['title'].nil? }, allow_destroy: true accepts_nested_attributes_for :dones, :todos, reject_if: :all_blank, allow_destroy: true # 親のレコードを更新時に子のレコードも保存される と、accepts_nested_attributes_forを2行にして、わかったこと(knowledges)のほうにはreject_if:にprocを与え、blankではなくnil?で条件判定をさせる。空文字が入っていればnilはfalseを返すので削除されない。削除されないのでその後のバリデーションにも通すことが出来る！ 一覧画面→編集画面に遷移時、Bootstrap-tags-inputのjQueryがうまく動いていないので、turbolinkを編集画面でのみoffにした→無事動いた 【CSS】要素を右寄せにする場合は「margin-right:0」 /* 右寄せ */ #sample1 { margin-left: auto; margin-right: 0; } これだけで→寄せできることが分かった。しかもレスポンシブ的にもこっちのほうがよさそう 検証ツールから直接当たってるクラスを調べて、deviseのアラートに色付けできる deviseのパスワードの最低文字数は、configのdevise.rbをいじる 次やること 各ページのデザインの微調整 レベルアップのアニメーション？ ランディングページの作成 ナビゲーションバーを整える margin-rightとかfloat-rightについて調べる 要件定義から変えたところをまとめてメンターに送る準備

やったこと ユーザー関連ページのデザイン。思ったより多かった（deviseが作ってくれたページがたくさんあった） ボタンをブロック化したり、ボタンの中にfont-awesomeのアイコンを埋め込んだりした tags-inputのタグ入力時に、文字が見切れるのを直した form-rowを使って、複雑なフォームレイアウトに挑戦した（一応成功した） cocoonのフォーム追加・削除ボタンをfont-awesomeに置き換えた……が、横並びにしようとfloat-rightを使うと、追加されたフォームに余計なpaddingがかかり、うまくいかなかった formのborderの色を変えたり、formが入力待機状態になっている時の影の色を変えたりした 検証ツールをたくさん使うことで、CSSのいじり方が少しずつ分かってきた わかったこと formをグリッド的に整理して並べるときはform-row cocoon + simple_formでのlink_to_add_associationにfont-awesomeのアイコンやボタンを使うときは、 .links = link_to_add_association f, :dones, partial: 'logs/done_fields', class: "btn btn-sm btn-spacegreen d-inline-block" do - content_tag(:i, "", class: "fas fa-plus") = link_to_remove_association f, class: "btn btn-sm btn-spacegreen mb-1" do - content_tag(:i, "", class: "fas fa-minus") formの枠線の色を変えたいときは、対象のform-controlのborderの色を変える formが入力待機状態になってる時の影の色（デフォルトでは青）を変えたいときは、form-controlの疑似要素focusのborder-color, box-shadow,outlineをいじる tags-inputで作ったタグ入力フォームで、文字を入力している際に見切れる場合は、input要素のwidthをいじれば良い 左に寄せたいリンク要素をfloat-left d-inline-blockで、右に寄せたいリンク要素はfloat-right d-inline-blockで、左右に分けて配置できる 検証ツールから値をいじったり追加することで、どこのセレクタのどのCSSをいじれば良いのか分かる ただし配置系はそれじゃ無理なのでCSSを根本から理解する必要がありそう 影の色を変えたり枠の色を変えたり、余計なことは出来るのにボタンやテキストの位置を自由自在に揃えられないのがもどかしくて仕方がない 次やること 投げずに続けること デザイン100点を目指してたらキリがないので60点ぐらいでまず終わらせることを目標に進める 検証ツールをいじりまくる logの残りのviewのデザインをがんがん進める

やったこと font-awesomeのアイコンをcard-headerの右に設置 デザイン系のissueをまとめて立てる ユーザー系はマイページのデザインから着手する ジャンボトロンを使って上部にはユーザーの情報 その下にはボタンを横並びにしてYWTの数を表示 font-weight: lighterでいい感じになった users/show.scssファイルの変更が反映されず、色々試すも解決できない アセットパイプラインについて調べるも、下に書いてあるし優先されるように読み込んでいるはず しょうがないのでapplication.scssにCSSを書いていく 要素を浮かせてジャンボトロン内でうまい具合に配置する レベルに必要なExpをプログレスバーで実装。ちゃんとユーザーの経験値とバーが連動するように バーのwidthを求める式をコントローラに書いた わかったこと application.scssに書けばとりあえずデザインはあたる 後に読み込まれたファイルや呼び出された要素が優先される プログレスバーのwidthに変数を使うのは#{}だけでいける fdivで小数点まで求める割り算が出来る 検証ツールで、どのファイルのどの文章でどのようなスタイルが当たってるか全部わかるのでCSSのデバッグはこれを頼りにするしかない btn-groupが便利。ボタンを横に同じ幅で並べたいときいいかも 次やること ユーザーの他のページのデザインを実装する users/show.scssファイルがなぜあたらないか引き続き調べる font-weightを気にする けっきょく、よはくを読み返してデザインを考え直す

やったこと indexページのデザインに取り掛かる ラフ画から、パーツ毎に切り出して四角で囲ってみる containerに入れてみる どんなパーツか必要か洗い出したら、まず3列でY,W,Tを分けてみる Yのカードを置いてみる Yのカードのデザインを進める 3つ並べた時、Logの日付の表示やまとまりをどうするかを考え、LogのカードでYWTのカードを囲むのを試す 意外とうまくいったので採用 やったことの詳細をクリックで開閉したい→折りたたみを使ってみることにする 普通の折りたたみは実装出来たが、一つを閉じると全てのカードが閉じてしまう→トリガーにしているid名を、それぞれのY,Wで別にもたせる必要がある idやクラス名を動的に指定する方法を調べ、やってみるも今度はBootstrapのオプションが動かない 仕方なく、slimで書くのを諦めてその部分だけまずhtmlで書いてみる 動くことを確認したら少しずつslimで直していく クリックして現れるコンテンツのIDと、ボタン化したヘッダーのIDに同じものを設定していたせいで、開いたものを閉じた時、要素がなくなってしまう望まない挙動に→単なるスペルミス。だけど2時間ぐらいハマった Bootstrapに新しいテーマカラーを導入する Index最上部にやったこと　わかったこと　次やることのボタンを表示させたかったけど、ボタンの色が変えられずに詰まった わかったこと slimのちょっと複雑な書き方。ちゃんと公式リファレンスにもあった。 div*{id: "#{@instance_variable_1}", class: "#{@instance_variable_2} container-fluid"} role="button" aria-expanded="false" のように、divの後*で囲う。オプションはカッコの外で書ける。 カードの中にカードが入れられる！ Bootstrapのテーマカラーは簡単に増やせる（楽しい） slimのインデント要整理 slimがわからなくなったら、一旦HTMLで書いて一行ずつslimに直していくと問題箇所が分かるかも？ 公式リファレンスをよく読む CSSの優先度？について調べないとカスタムして増やしたテーマカラーのボタンの文字の色は変えられないかも 8時間やった割には進みが悪い。もっとテキパキ書きたい 色で悩まずにとりあえずこの色で行く 次やること Index、7割ぐらいでいいから完成させる カラーはとりあえずこれで進んでいく 時間を無駄にしない リファレンスを読みこむ 一行ずつhtmlからslimに直す div*を活用していく

やったこと レベルアップ機能の実装に取り掛かる テーブル作成 Qiitaの記事を参考にレベルアップのサンプルアプリ作成 動かすためには経験値テーブルが必要で、経験値テーブルを色んな式試しながら作成 Googleスプレッドシートに入力し、グラフを見ながら調整 うまく動いたので、本番アプリに導入 レベルアップ機能自体はすぐに実装できた モーダルウインドウでレベルアップの表示をするために、Bootstrapのモーダルとプログレスバーについて調べる レベルアップ前のレベルを取得し、何レベル上がったかを表示するため値の受け渡しについて調べる わかったこと レベルアップ機能は2つのテーブルを作って経験値テーブルさえあれば簡単に実装できる 経験値テーブルは奥が深そうなのであまり深堀りするべきじゃなさそう 値の受け渡し。link_toだけでなくredirect_toでも値が受け渡せる モーダルでポップアップウインドウが表示できる BootstrapとjQuery使えばプログレスバーに変数を渡して動かせそう 次やること レベルアップ機能の細かいとこの調整 モーダルとプログレスバーの実装 終わったらいよいよ見た目を整える

やったこと acts-as-taggable-onを別の記事を参考にサンプルアプリで試す internet archiveで削除された記事を見る→成功 サンプルアプリでうまく行ったので本番環境でも導入 確認画面に移行するまではカンマで区切ったタグは別のものとしてパラメーターが渡っているのに、updateアクションが走るとカンマが消えタグが1つにまとまってしまう →hidden_fieldにtag_listを渡し、そこでもjoinをかけることで解決 Bootstrap Tags Inputを導入するも、タグを追加しても表示されなくなってしまう 一度ここまでの変更を破棄し、jQueryのTag-itを使おうとするも、結局動かず もう一度Bootstrap Tags Inputを導入し、原因を探る 最初はcocoonやnested_fieldのせいかと思ったが、Bootstrap2環境で作られたTags InputがBootstrap 4系とは違うクラス名を持っていただけだった jsファイルのlabelをbadgeに書き換えて無事成功 タグでの検索機能も実装 わかったこと Tag-itやBootstrap Tags Inputのように、公式リファレンスが思ったよりしっかりしてないものが結構ある 有用そうな日本語情報は削除されててもInternet Archiveにログが残ってることがあるので頼りにする acts-as-taggable-onはタグ用のテーブルすらも初期設定で用意してくれるし、タグでの検索もメソッド一つで実装できる恐ろしいくらい便利なgem タグが表示されなくて焦ったが、要素の検証で、タグ自体は追加されているが見えないだけ、ということにたどり着いたのはめちゃめちゃ良かった 表示されないだけならCSSをいじればいい 次やること 見た目を整える タグ機能すみずみまでテスト ユーザーレベルアップ機能

やったこと カテゴリー機能を実装するための方法について調査 gemを導入するかしないかで迷う gemを導入せずTag-itというjQueryのライブラリだけ使おうと思うも、うまく動かない gemを導入してサンプルアプリで試そうとするも、うまく動かない 再度gemを導入してサンプルアプリで試すも結局うまく行かない

やったこと cocoon導入後の挙動テスト cocoonでのレコード削除がうまくいかなかったので試行錯誤 サンプルアプリで、レコード削除が出来ていることを確認 メンターに質問、人に話すことで現状整理 質問後、パラメータをチェックすると_destroyが渡ってないことに気づく confirmのviewに、hidden_fieldで:_destroyを渡すことで削除可能に ywtが一つも登録されていないlogを編集時に、add column的なボタンが表示されないのを確認 action_name == "edit"かつlog.donesがnilの時にviewの表示を変えようとするも、インデント調整で無事表示できた わかったこと binding.pryでいちいち止めて、いちいちパラメータを確認することで自力でエラー解決できた サンプルアプリがあると、正しい挙動をすぐに比較・確認できるのでとても助かる メンターに質問することで、疑問点や正常に動くのはどこまでか、が整理されて見通しが立つ slimはインデントに気をつける categoryはYとWに追加するのではなく、logへの追加のほうがスマートかもしれない user-category-ywtが親子孫関係 次やること カテゴリー実装 カテゴリーのテーブル設計考え直し レベルアップ実装

やったこと Cocoonをまずテストアプリで導入 テストアプリ通りに導入して動くかどうか試す jQueryが足らなかったのでインストール 無事動いたのを確認し、卒業制作にもcocoonを導入 モデル・コントローラを編集 viewを編集するがうまくいかず…… 結果スペルミスだったので直してうまく動くようになった わかったこと 動的〜系にはJavaScriptが必須なのでjQuery等がしっかりインストールされてるか確認すること 一つのスペルミスでハマるので慎重に書く adminのgemはdeviseと組み合わせると凄く便利そう cocoonを使うと動的追加・削除するフォームは別のviewに渡せる 次やること レベルアップ機能の実装 カテゴリー機能の実装

やったこと userとlogsを一対多で関連付けた current_user.logs.buildと書き換えた それに伴って色々なところが動かなくなったので直した stack overflowの英語で書かれてるようなQAも読んだ binding.pryでたくさん止めた ストロングパラメータ、require、permitについて調べた 親子孫なモデルの更新について調べた わかったこと ネストしたモデルの更新では、子モデルのidを持たせて同じものが既に存在するかどうか調べないとupdateではなくinsertで新しく作成されてしまう エラーメッセージにほとんど書かれてる。idがないよと言われてたけどそんなことないだろと思いこんで別のところをいじってた 一対一と一対多ではbuildの書き方がどうやら違う f.fields_for :dones, logs.dones という書き方にしたら直った……？ hidden_fieldsでidも渡してあげたら直った 確認画面は今自分が実装してる方法よりもっと簡単に実装できる 次やること 次こそcocoonの導入 エラーメッセージをしっかり読む cocoonの公式リファレンスを読む いきなり導入せずサンプルアプリで試してから導入する

やったこと 最低限のYWT CRUD関係画面（削除はまだ） 新規作成フォームを整える simple_formの使い方のお勉強 accepts_nested_forで親と同時に子のデータも保存できるように 親・子・孫関係をノートに書いて整理 新規作成・編集に確認を挟むように（仮実装） 複数のフォームを動的に追加する方法を調べる todosテーブルのcommentカラム削除 わかったこと simple_form便利 simple_formじゃ思ったような挙動にならない時は普通のform使う simple_form使わないパターンの時、hintが使えなかったが検証でhintが作るhtmlをそのままコピーすることで解決した simple_formにBootstrap適用するinstallをしないとだめ accepts_nested_forで親子同時に保存できる。めっちゃ便利 だけどRailsの作者はこれ嫌いらしい Cocoonの使用を検討するがいったんやめに inverse_ofはRails5系ではhas_many等でアソシエーションの設定されてればわざわざ書かなくてよい 定期的にデータベースのリセットかけたほうがよい 次やること ユーザーとログの関連付け Cocoon or Vue.jsの導入？ デザイン？

やったこと Deviseの導入 Deviseを使った最低限のユーザー機能 OAuthを使ったGoogleログイン機能 最低限のマイページ 最低限のユーザー編集ページ パスワードの変更がない場合、そのほかのユーザー情報は現在のパスワードを入力しなくても更新できるように 何回も手戻り。その度にgit resetや切ったブランチを破棄してdevelopmentからやり直し git revertをはじめて使った わかったこと 慣れてない技術を触るのはとっっっっても大変 何をするにも恐る恐るだしエラーが出た時にあたりが全くつかない git revertはめちゃくちゃ便利。特定のコミットを無かったことにできるし、無かったことにしたというログも残る 未知の技術を触るとき、日本語情報に頼りがちだが最終的には公式リファレンスの読み込みとトライアンドエラーが一番早い ストロングパラメータの許可は配列でまとめちゃえば楽 editのURLが使いたいからといって別ページを用意する必要がなかった。rails routesをよく見よ エラーメッセージで検索して何も出てこなかったら思い切って手戻りするのは意外と良かったかも 雨の音流すと集中できる 次やること 雨の音使う ナビゲーションバーぐらいはBootstrapで整えてもいいかも Git Revertを使っていく 慣れない技術を取り入れるときは日本語情報を頼りにする前に公式リファレンスを読んでみて、テストアプリでやってみること Deviseは便利だから自分で作らなくても用意してくれてるかも？を考える 諦めずにコード書いていく

やったこと タスクの洗い出し Trelloにカード作ってみる Jootoのほうが見やすいのでJootoに移行 どこから手をつけていいか悩んだがユーザー機能からやることに Deviseを使うのが2回めだからとりあえずカリキュラム読んでサンプルアプリで試す 自分のアプリに導入するもslimへの変換がまずったのかうまく動かないので一旦戻す SNSログインを実装したいのでOAuthをカリキュラムで勉強、サンプルアプリで試す→Googleログインは実装成功 自分のアプリでGoogleとTwitterログインを実装するも、TwitterはちゃんとしたURLが無いのでだめ、Googleログインもなぜかエラーが出て失敗 わかったこと 時間がない ガントチャートまで作らなくて良さそう Vue.js周りに関してはアプリで実現したいことを実現するための技術だけキャッチアップする Devise便利だけど公式ドキュメントをあんまり読んでないので魔法がおおすぎて怖い Twitterログインはデプロイ後の実装になりそう ポモドーロタイマーが邪魔になってたかもしれない 次やること Googleログインのエラーを解消する ポモドーロなしでやってみる 集中力が切れがちなので対策を考える デザインは後回しにする

やったこと いちいちコメントを追加した 長ったらしいHTMLは自分で書くのではなくサンプルコードをコピペした JavaScript部分、Vue.jsに関する部分はしっかり手打ち わかったこと 一度モックアップとしてHTMLだけで書いてみてからVueに置き換えるというのが最初はやりやすそう 目に見えるデータを洗い出し、dataに変数として持たせて表示させられないか？を考える データを直接マスタッシュでバインドすることで簡単にデバッグできる。console.logでやらなきゃいけないような処理もある？ 次やること 3章終わらせる わからないことは引き続き公式ガイド読む 書かなくていいコードは書かない！

やったこと 一度やったテキストの復習 コードとテキストを読んで、疑問に思ったところを調べる それでも分からなかったら質問する 忘れそうなとこはBoostnoteに記録しておく Rails + Vue.jsのアプリを作成するにあたってどうしたらいいかYahooの現役エンジニアで執筆者の方に質問した わかったこと Vue.jsの公式ガイドはすごい。よく読めばだいたい知りたいことが書いてある axiosを理解するのにJSON、API、promiseの知識が必要 data内にreturnの有る無しはコンポーネントを切る、切らないで違う。でもとりあえず関数化してreturnしておけばよさそう 非同期処理の成功・失敗によって分岐させるのが.then。成功のときはthen, 失敗のときはcatch以降の処理を実行するって感じ persistentはVuetifyのv-dialogのオプションみたいなもの。要素の外側をクリックしても、ポップアップしてきたダイアログが閉じずにアクティブなままになる アソシエーションが複雑なモデルを扱うとき、データベースの設計等をしっかりすること、jsonを持ってきてVue.jsには描写や加工だけやらせたほうが楽なこと 次やること axiosと仲良くなるために周辺技術や用語についてもっと詳しく調べる Boostnoteに引き続き記録していく

やったこと TechCommitで薦められた本含め本屋で色々と見てきた 基礎を固めることを決意 似た動きをするけど違うコードについては公式ガイドを読んで理解を深める Boostnoteにもまとめる わかったこと v-showとv-ifは見た目的には同じだけどやってることは違う 条件に当てはまらないとき v-showはDOMに要素が出力される、CSSのdisplay:noneが適用されて表示されない v-ifはDOM自体が出力されない v-forで繰り返すとき、v-bind:keyを使ってPK的なものを与えてあげる必要がある 次やること フォーム入力バインディングの公式ガイドと参考書の記述をしっかり読んで実践してみる わかりにくいとこは引き続きBoostnoteにまとめて後で見返せるようにしておく

やったこと Axiosで取ってきたデータを処理したり、検索機能や絞り込みを実装した わかったこと Axiosで取ってきたデータをいじくり回すあたりが全くわかってない Techpit教材をやったものの、Vue.js周りに関しては初歩的な部分以外全くわかってない 次やること Vue.js周りのコードを一行一行しっかり読み解きながらもう一度作ってみる？

やったこと ER図をIE記法に Vue.jsとRailsを使う時、どうやってRails側のデータをとってくるか調べた わかったこと jsonをとってくるのとAPI化するのがある 次やること 要件定義をもっと詰める

やったこと 要件定義見直し テーブル設計、PKとFKを記述 使用gem、"simple_form"について調べる Snippetアプリの環境構築 わかったこと simple_formは5.2.4ではそんなにコードの量が減らないし、もしかしたらわかりにくくなるだけかも？ Primary KeyとForeign Keyを記述すると分かりやすくなる 次やること ER図をIE記法で書き直す Snippetアプリをガンガン進める

やったこと 画面遷移図を見ながらラフ画をCacooで作った。 一覧画面は苦戦しそうだったので紙とペンを使った。 一覧画面は苦戦しそうだったので後回しにした。 わかったこと Cacooは超便利。キレイにできれば出来るほどテンションが上がる。 時間かかりそうなやつは後回しにして、できそうなやつから片付けて行ったほうが時間に追われてる身には良い。 わざわざページを用意しなくても実装できそう（ユーザー編集画面とか） 画面を作ると機能の見直しにもなる 次やること 一覧画面以外をぱぱっとつくる。 一覧画面に向き合う。 機能の見直しもする。

やったこと 画面遷移図を見様見真似で作ってみた。 わかったこと Cacooでは矢印の終点のスタイルを指定することで矢印が出来る。 画面遷移図を書くと実際に作らなきゃいけないviewや処理が明確になる。 次やること 画面遷移図の細かいところを詰める。 ワイヤーフレームに取り掛かる。 画面遷移図は今後も必ず作ってからアプリを作成したい。