niwa

独学 ： VBA, Java スクール学習内容 ： HTML/CSS, JavaScr…

niwa

独学 ： VBA, Java スクール学習内容 ： HTML/CSS, JavaScript,Ruby,Ruby on Rails, GitHub,GitHub Desktop,Heroku,PAY.JP,AWS(S3)

  • ビジネスモデル・ジェネレーション

    ビジネスモデル・ジェネレーションを読んで感じたことをアウトプットするマガジンです。

  • 学習方法の改善

    ●結果の出る(モノが作れる/実務ができる)効率的な学習方法を身に着けるため ●学習を習慣にするため(生活の一部に)

  • 仮説と検証

    日々の学習で行った仮説と検証をちょこっとpick up。 質問前に書き起こした質問フォーマット＋回答内容まとめ。

  • アウトプット

    学習毎に行なっていたアウトプットを発信に転用。 日々のプログラミング学習で学んだことを、言語化。

  • テックキャンプ

    進捗＆実際にスクールで学んで感じたことを。

「ビジネスモデルとは」を、言葉にできるか

ビジネスモデル・ジェネレーション さて、 この本は、何について書かれてるのか？、と 導入部分を読んでいると、 と書かれていた。 ビジネスモデルについて書かれているようだ。 そもそも「ビジネスモデル」とは何か？ ちょっと検索してみた結果、一言でまとめると 「事業が収益を上げる仕組み」だと解釈した。 しかし、 ページをめくっていくと、こんな定義が書かれていた。 この定義を見て、ビジネスモデルに対する解釈が違っていた事に気づく。 「プラスになる価値があり、 それをどう

niwa

    • アウトプットを習慣に・その2

      前回対策を挙げたが、続かずに投稿が空いてしまった。 原因と対策を考えた。 原因・学習フェーズが代わり、実装が多くなった ・実装の方が楽しく、そちらに注力した ・note投稿用に、メモを編集する作業が面倒だった ・詳細が気になることが多くなり、調査・考察・質問の回数が増えた ・その結果、一時的に進捗が計画と同じペースまで落ち、投稿の時間を確保しないようになった ・できてないときほど、「やらなきゃ」と思うことが多くなり、 先延ばしにしている感覚と義務感が、感情的な面に影響

      niwa

      • コメントアウトが無効な記述

        ●コメントアウトされているのに、なぜ動く？app/assets/stylesheets/application.css /** This is a manifest file that'll be compiled into application.css, which will include all the files* listed below.** Any CSS and SCSS file within this directory, lib/assets/sty

        niwa

        • [output] 多対多 の DB設計

          多対多の関係をもつテーブルがある場合、カラムに問題が生じる。 お互いに相手テーブルのidを複数持っているが、1つのカラムに複数の値を入れられない。 かといってidごとにカラムを増やしてしまうと、レコードによっては不要なカラムが生じてしまう。 それを解決する方法として、中間テーブルの活用がある。 中間テーブルとは、2つのテーブル間にあるテーブルのこと。 2つのテーブルの組み合わせパターンだけをレコードとして保存する。 この場合、モデルのアソシエーションにはthrough

          niwa

        「ビジネスモデルとは」を、言葉にできるか

        niwa

        マガジン

        • ビジネスモデル・ジェネレーション
          1本
        • 学習方法の改善
          2本
        • 仮説と検証
          7本
        • アウトプット
          9本
        • テックキャンプ
          1本

        記事

          [QA]buildとFakerのつかいわけ

          投稿機能の結合テストのおけるbefore内の記述について。 ●なぜTxetインスタンスをbuildしないのかRSpec.describe "テキスト投稿", type: :system do before do @user = FactoryBot.create(:user) @text = Faker::Lorem.sentence end FactoryBotのtexts.rbファイルには、 アソシエーションの記述がある。 FactoryBot.define

          niwa

          [QA]buildとFakerのつかいわけ

          niwa

          [output]サポートモジュール

          結合テストでは、「ログインする」というステップを何度も記述した。 テストコードにおいても、繰り返し行う処理をメソッドとして切り離せる。 RSpecでは、サポートモジュールというものを利用して行う。 方法は、specディレクトリ以下にsupportディレクトリを作成。 そこに、.rbファイルを配置。 モジュール名とファイル名は同じにし、名前で何をしているかわかるようにする。 ■spec 　■suppor 　　□sign_in_support.rb #サインインのモジ

          niwa

          [output]サポートモジュール

          niwa

          RSpec.describe と describe

          ●解決したいこと①と②は、どんな違いがあるのか。 また、どう使い分けるのか、疑問に思った。 require 'rails_helper' #binding.pryRSpec.describe "外枠describe", type: :request do #####① before do end describe "内側describe" do　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　#####② ●仮説と検証rspecコマンドでファ

          niwa

          RSpec.describe と describe

          niwa

          [output]Rspec結合テスト

          ●System Spec結合テストは、System Specを用いて記述する。 記述には、カピバラというGemが必要だが、Railsが標準搭載している。 #Gemfilegroup :test do 略 gem 'capybara', '>= 2.15'略end`` そのため、導入処理不要。 ファイル生成は、bundle exec rspec:systemコマンドを実行する。 生成するファイル名の指定は、複数形で行う。 結合テストは、ユーザーの操作を再現しながら 想定

          niwa

          [output]Rspec結合テスト

          niwa

          新規登録失敗後のURLが/userのわけ

          ●new_user_registration_pathでなく、 　user_registration_pathになる理由。 ・解決したいこと新規登録に失敗したら、登録ページに戻されることを 確認する記述について。 #spec/system/users_spec.rb# 新規登録ページへ戻されることを確認する expect(current_path).to eq(user_registration_path) binding.pry deviseのregist

          niwa

          新規登録失敗後のURLが/userのわけ

          niwa

          describeとcontextとit

          ●describeとcontextとit・解決したいこと現在実装しているテストは下記のようになっている。 ・モデル単体テスト：describeとitでグループ分け ・コントローラー単体テスト：describeとcontextとitでグループ分け ・結合テスト：contextとitでグループ分け describeとcontextとitを使い分ける考え方について。 ・調べた内容、仮説itでわけたグループがexampleとなる。 テストコード実行後、成功/失敗したテスト数が 「

          niwa

          describeとcontextとit

          niwa

          [output]コントローラー単体テスト

          コントローラーの単体テストについて。 コントローラーのテストは、リクエストに対して想定したレスポンスが生成されるか確認する。 例えば、レスポンスの情報を使って、 ・正常にレスポンスが返ってきたかをHTTPステータスコードで ・そのページに表示されるはずの情報が存在するかをbodyの情報で 確認する。 詳細は、後ほど。 まずは、コントローラーのテストファイルの作成から。 これには、rails g rspec:requestコマンドを使用する。 rails g rspec

          niwa

          [output]コントローラー単体テスト

          niwa

          [output]モデル単体テスト

          モデル単体テストは、バリデーション及びメソッドの検証。 異常系テストにおいては、 presence: trueというバリデーションがあるなら、 カラムを空にして、エラーメッセージを検証する、と バリデーションを参考にイグザンプルを組み立てやすい。 対し、正常系テストは、 アプリの仕様・動作の流れも参考にして、組み立てる必要がある。 例えばユーザー登録というdescribeならば、 「○○と△△と□□のデータがあれば、登録できる」というイグザンプルの検証が必要になる。 バ

          niwa

          [output]モデル単体テスト

          niwa

          [output] FactoryBot と Faker

          ●FactoryBotRspecでテストを行うにあたり、 テスト毎にインスタンスを生成するのは 非効率かつ、可読性が落ちる。 そのためFactoryBotというGemを使用し、 テストで使用するインスタンスをあらかじめ設定しておく。 導入方法は、まずGemfileに下記を記述。 group :development, :test do # Call 'byebug' anywhere in the code to stop execution and get a deb

          niwa

          [output] FactoryBot と Faker

          niwa

          Rspec

          1 : r.specに「--require rails_helper」を記述しない理由1 : 仮説検証Ruby機能をテストするための設定である 「--require spec_helper」はr.specファイルにデフォルトで記述あり。 「--format documentation」を追記するなら、 「--require rails_helper」も記述すればいいのでは、と考えた。 だが、Railsを使った機能のテストファイルを rails g specコマンドでファイ

          niwa

          Rspec

          niwa

          [Rspec/テストコード]今日の学習アウトプット！

          テストコードとは、アプリケーションの動作確認をするために書くコード。 品質の担保のために重要な工程。 また、どんなテストが必要か把握するには、アプリの仕様への理解が必要。 逆言うと、テストコード記述は理解を深めるのを助ける。 理解を深めるにあたって、ポイントは３つ。 ・細かい記法は、使用する際に調べれば良い ・それより、ここで何を確認したいのかを理解する ・挙動で気になる点があれば、処理を止めて確認する Rubyのテストコードは、RSpecというGemを使用する。 標準

          niwa

          [Rspec/テストコード]今日の学習アウトプット！

          niwa

          Git/GitHub

          ●リモートリポジトリでのトピックブランチ削除が、 ローカルリポジトリには反映されないがなぜか。・仮説リモートレポジトリでmerge後、トピックブランチを削除。 その後、ローカルでpull作業をした直後。 ローカルリポジトリのBranchタブでは、 リモートで削除したトピックブランチを選択可能。 ただし、DELETEが選べる。 pull = fech + merge fech = リモートリポジトリの最新の状態を取得 merge = トッピクブランチをmasterブランチに統

          niwa

          Git/GitHub

          niwa