Day2_オリジナルアプリ
アプリ概要をnumbersにまとめた。
- アプリ名
- そのアプリの目的、解決したい問題
- 問題が起きている理由
- 解決方法
- 考えられる懸念
- アプリを利用するのは誰か
- なぜこのアプリを利用するのか
- どの様に利用されるか
要件定義をnumbersにまとめた。
- index
- 機能名
- 目的
- 重要度
Day1_オリジナルアプリ
開発手法の決定
開発手法は、大きく分けてウォーターフォール型とアジャイル型がある。ウォーターフォール型で開発するのは、”大規模で何を作るのか”がはっきりと決まっている場合。特徴としては、予算や納期のコントロールがしやすい反面、開発の途中で要件の変更があるとどんでん返しを食らう。一方、アジャイル型で開発するのは、不確実な仕様の時。特徴としては、仕様の変更に柔軟に対応できる反面、予算や納期が不透明になりやすい。- 一人アジャイル型
理由
仕様があまり決まっていないため。また、ユーザーファーストでユーザーテスト基に改善をしたいため。その際に、デザイン(アプリが実現したいことを正しく伝えるための設計)も早めに導入しちゃう。
4章 プロになるRuby入門
この章で学ぶこと
- 配列
- ブロック
- Range
- 繰り返し処理
- 繰り返し処理用の制御構造
ポイント
- 配列の要素をあれこれいじくり回すようなコードが描きたくなったら、手を動かす前にAPIドキュメントに一通り目を通して使えそうなメソッドはないか探す
- こんなコードを書こうとしているのは、世界で自分だけか？ 自問する。
- 以上の過程を踏むことで、簡潔なRubyプログラムがかけるようになる。
配列
- 配列を使っても多重代入できる。多重代入は配列として返してくれるので、divmodのようなメソッドには有効p89
ブロック
- rubyにもfor文があるが、ほとんど使われない。rubyでは、eachメソッドを使い、配列自身に対して繰り返せと命令する。
- 同じ処理を違う言語で比較するとrubyのブラックボックスになってしまっている部分が浮かび上がってくるので面白い。
- Rubyでは、要件を問わず共通する処理はメソッド自身に、要件によって異なる処理はブロックにそれぞれ分担させて、一つの処理を完了させるメソッドが数多く用意されている。
- delete_if は、”配列要素を順番に取り出すこと”と”ブロックの戻り値が真であれば要素を削除すること”という共通処理を提供する。
- |n| ← ブロック引数
- number.each { |n| sum+= n } のようにかける。( do → { , end → } に対応 )
- endの対義語はbeginだけど、doのほうが文字数短い
- 奇数/偶数：odd/even
- ブロックを使うと同じ名前でもオブジェクトidは異なる
Range
- Rubyでは、範囲オブジェクト(例. (1..5) )を使うと便利な場面がある
- 0 <= temp && temp < 100 は、(0...100).include?(temp) とかける
- 10進数 / 16進数 = decimal / hexadecimal
- + vs concatメソッド 違い：破壊的かどうか 大規模な開発では + を推奨
繰り返し処理
- ミュータブルなオブジェクト：stringクラス
- イミュータブルなオブジェクト：数値、シンボル、true/false、nil
- ↑ の違いは破壊的メソッドが使えるかいなか
繰り返し処理用の制御構造
- 繰り返し処理の脱出：break 大域脱出：throw, catch
- returnは、メソッドからの脱出
第3章 プロになるRuby入門
プログラマの三大美徳
- 怠惰：全体の労力を減らす為に手間を惜しまない（長い目で見たときに一番効率の良い策を練る）
- 短気：コンピュータの動作が怠惰なときに怒りを感じる（コンピュータの可能性を信じてる）
- 傲慢：自分の書いたプログラムは誰に見られても恥ずかしくない
テストの基本
- assertion check : プログラムの処理や条件の成立を表明するための手法や機能（略してアサーションと呼ぶ）
- テストコードを作成する手間はかかるが、そのあとの動作確認が素早く終われば、トータルで見て早く終わる。面倒なことは機械に任せる→怠惰
- テスティングフレームワーク → Minitest, test-unit, (この2つは標準インストール) ,Rspec(gem)
- "プログラムのアウトプットが明確"、"テストコードの書き方が最初からイメージできる"という2つの条件が揃っている場合はTDDが向いている
