wcコマンドをrubyで作る再提出
あまりにも指摘事項に対してチンプンカンプンだったのでペアプロお願いしました。 鉄は熱いうちに打てということで、分かったことと今後やるべき内容をまとめておこうと思う。
※チンプンカンプンって変換したら珍紛漢紛って出てきた。由来これなのかしら。
ペアプロたのも〜
実際見てもらう、アドバイスもらうのは苦手意識がついています。
なんで苦手になってるか過去の体験に遡る〜
というのも６年ほど前にjavascriptを勉強していたんですが、まだ大学出たばっかりで右も左もわからんし、 具体と抽象の質問で考えるとかなり抽象的に質問したのはわかる。
ただ・・・
当時テラテイルの粛清とも言えるアドバイスはほぼほぼマサカリに思えて。 質問するたびに怒られ、ググれカス言われる（実際ここまで言われてませんが婉曲表現好きな人いますよね）
そしてヤフ知恵に逃げ込んでも同じ感じの方が多い。 他の質問見てもわざわざ返信欄に「はあ・・・だから、」 と付け加えている。
わかる立場になるとわからんこともないけど、あんまりじゃない？ そうでもない？ここは初学者ぴえんポイントのはず。
何でこんなに言われないかんのか当時考えた
費用負担が安く学べるプログラミングなので、先駆者から見たら
- 夢見がちな若者に正義の鉄槌
- GRIDないやつに出る杭を打とうかね
- 誇大広告から夢見がちなやつにリアルを教えてやろう
- シンプルにもうちょっと調べ学習進めて知識持ってから聞こうぜ？（抽象→具体）
- 察してもらうようなテキストコミュニケーションやめれ
のどれかor複合で感じているかもしれない。
という過去の経験からちょっとテキストコミュニケーション震える。 ブルブルブル・・・
自分もこういった過去があったので、身近な人に 「プログラミング学習って私でもできる？」と不意に聞かれると返答に戸惑う。
でも言えることは、
- 仕事が効率的に自分で順序考えてできてたなら素地はあるのでは？
- 今後も使う機会があるのか？
- プログラミングで何がしたいの？
- かける時間と費用はこのくらいだけどOK？
- 続けられそうです？？
素地×時間×費用×気合い（継続力）
が高ければ高いほどできると思ってる。 ただできる≠習得ではない、プログラミング学習＝青天井
という過去があるので、ちょっと緊張はする。
そしてペアプロ前に大体昼寝してるので、寝ぼけてることがある（すみません）
wcコマンドの指摘事項
これとこれ共通化できますよね？
うん、何となくわかる。 ただ、自分が何でここ分けたのか思い出すのに10分ぐらいかかる。
一回作って放置して・・・
直してまた期間が空いて・・・
💡！
ああそうです。
🐙：「確か、ファイル指定と標準入力を見分けるのが必要かと思ってif文で冗長的になってました。」
メンターさん：「なるほど。でも・・・」
ここで指摘が入り、具体的なアドバイスをもらえた。
わかったこと
このメソッドをうまく活用しましょうということ。
文字列を返すreadと$stdinをうまく組み合わせて使いましょう。と
なるほど。
リファレンスは逆引きできない
何で今回こんな行き違いというか、わからない状態が続いたかというと、
最適なメソッド検索がわからないから起きたと思ってる。
結局標準入力の仕方をreadlines以外知らなかったんですね。
実際どこに何があるか、読書のごとくリファレンスを見ているというよりかは、 何か必要性があったときに探してみる。方が強い。
なので、
- こういう処理をしたいのでこういうメソッドが欲しい
- 「なんかワード」検索する
- それっぽい記事が出てくる
- 記事に書いてあるメソッドをリファレンスで調べる
大体この順序なので、この一つの工程に対して一つのメソッドしか知ることがない歯痒さがある〜 紙の辞書なら前後左右の事柄が視界に入るから一個調べても同時に何個も知識が入るけど、 4.でピンポイントに調べるから一つしか得られない。
結局リファレンスを隅々見ろよと言われたら、 そういうもんなんですね。としか言えない、ね。
それに逆引きできても日本語の表現なんてわんさかあるからヒットするまで頭の中で言い換え＝変換を繰り返してグーグルさんにお願いするしかない。 「〜 ruby」「ruby 〜」「メソッド 〜 ruby」・・・とか何回検索したことか。
- でもこの地道な作業を乗り越えた先に先駆者はいるのかしら。
- それとも新卒入社で入ってOJTで先輩がきっちり現場知識叩き込んでくれた人々なのか。
わからないけど、マサカラナイでといいたい。
この検索作業は地味にストレスですね。 いい方法求む・・・
直すべき項目
- 先ほどのメソッドで一つの変数で扱う
input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : readlines)
- 標準入力かファイル指定の値か変数を識別する処理が必要
一つの変数（input内容）に対して同様の処理を行うことでリファクタリングしてるのであれば、 この識別が必要になるよね。
🐙：「こことこれで〜・・・仮にディレクトリ内部に1つしかファイルが存在しない場合の標準入力とファイル指定の変数に対する識別はどう・・・？」
メンターさん：「・・・それを考えるのも課題なので・・・。」
🐙：「ですよね(💦)」
学校のテスト中に先生に質問して返される時と同じ現象が起きた。
なので変数に与えた内容が標準入力でもファイル指定でも同様の処理で済むように工夫が必要ということ。 そして考えないといけないのは上記の識別方法というところ。
うーん。
一晩寝かすか。（やれよ）
RESTの考え方を理解する
RESTってなんだ？
Webサービスの設計モデルらしい。REST化したWebサービスはHTTPメソッドでアクセスするとデータの送受信をクライアントとサーバーサイドでやりとりしてくれる。
色々あるアーキテクチャスタイルのうち、クライアント／サーバーの設計が有名である。そのうちのRESTはアーキテクチャの中で色々と制約をつけてコンパクトにしたもののイメージ。
そしてRESTは複数のアーキテクチャスタイルから組み合わせて構築した複合アーキテクチャスタイルを指す。
RESTアーキテクチャの構成
- ステートレスサーバー
- キャッシュ
- 統一インターフェース
- 階層化システム
- コードオンデマンド
この1~4項目に即したWebサービスはRESTfulと言われる。
リソースとは？
Web上の名前を持ったありとあらゆる情報 このリソースを識別するにはURIを使います。
URI
統一リソースの識別子 これにより全てのリソースを一意に示せる。
URIが備える、リソースを簡単に指し示せる性質はアドレス可能性と呼ぶ。 リソースに対して名前がついていて、適切な手段でアクセスできる状態
http://blog.example.jp/entries/1
これをそれぞれ分解すると・・・
こんな感じになる。
他にも、
- ポート番号
- クエリパラメータ
- URIフラグメント
がつくアドレスもあるよ。
クエリパラメータは検索で何かデータを渡したときに入ります。
それぞれの役割
1 ステートレスサーバー
サーバーはクライアントのセッション情報を保持しません。
多数アクセスに対してセッション情報を保持し続けて、アクセスに対してそれを提示するのは大変。 なのでステートレスがいいという話（多分）
2 キャッシュ
これは以前サイト作成で苦戦した覚えがある。 クライアントサイドで訪問したサイトのデザインやらを記憶している。
ネットアクセスが読み込みスムーズになるメリットに対して、リソースを色々変更した場合に反映しにくい。 キャッシュを削除しないと更新状態が見えなかったりする。
ウルトラリロードとかつけてた気がする。（そんな名前の機能だったかも忘れた）
3 統一インターフェース
CRUDもRailsの知識として聞いたことがある。 URIのリソースに対してHTTPメソッドそれぞれ操作するよ。
| 処理 | HTTPメソッド | CRUD操作 |
|---|---|---|
| 登録 | POST | CREATE |
| 取得 | GET | READ |
| 更新 | PUT | UPDATE |
| 削除 | DELETE | DELETE |
処理結果に対する返答のステータスコード
| コード | 状態 | 説明 |
|---|---|---|
| 200 | OK | リクエストが正常に処理された |
| 201 | Created | リクエストが正常に処理され、新規リソースが作成された |
| 204 | No Content | リクエストが正常に処理されたが、返す新規情報はない |
| 400 | Bad Request | サーバーが理解できない無効な要求である |
| 401 | Unauthorized | 要求されたリソースには認証が必要である |
| 403 | Forbidden | 要求されたリクエストは拒否された |
| 404 | Not Found | 要求されたリソースはサーバーに存在しない |
| 500 | Internal Server Error | サーバーでエラーが発生した |
4 階層化システム
サイドバーのカテゴリとかも階層構造になってたりしますね。プログラムのディレクトリの階層構造も然り。
何となくイメージできるものは説明は割愛。
5 コードオンデマンド
プログラムをサーバーからダウンロードし、クライアント側で実行するアーキテクチャスタイル ex:Javascript, Flash,Java アプレット
クライアント側をあとから拡張できるよ。
でもアプリケーションのプロトコル可視性は低下する懸念もある。
引用：qiita.com
引用：
ツイッターのER図を作る
正規化がとても難しい
正規化については、動画と著書で6割理解と後残りは実践だと思ってる。
正規化とは？
- 表の横方向の重複整理
- テーブルごとの縦方向の重複整理
- 1対nの関係で切り出していく
第２正規化がまだいけるんじゃない？の自問自答で煮詰まる。
ひとまずpostalkでざっくりリスト化
最初こんな感じで考えた
でもテーブルごとにID付与しないとだめだよね・・・？
ひとまず、リスト化はここまでで作ってみる。
draw.ioでER図作成
draw.ioのsoftwareを選ぶと使いやすい。鳥の足とか用意してくれてる。
1対nの意識が難しい・・・
課題とモヤモヤ
- まだ正規化できるんじゃないか？やっていいのか？という迷い
- 特に画像のテーブルを作った方が良いか？
- ハッシュタグはプロフィールやツイートごとのテーブルにそれぞれ付与でいいかな？
重複するようなものなのか、煮詰まると正確に判断できなくなってくるなあ。
ER図について正規化の考え方
ER図の正規化についてまとめる。
なるほどなるほど正規化
第1正規化から第3正規化まであるけれどちょっとわけがわからなかった。 やってることがなんとなくわかるようでわからないというイメージ。
この動画を見るまでは「重複をなくす」というイメージのみでした。
わかりやすい動画発見
これはわかりやすい・・・ ER図がちょっとだけ書けそうと思った。
ふむふむ。
正規化は表の縦と横の繰り返しをなくす
正規化のステップ
第一正規化👉横方向の繰り返しをなくす
第二正規化👉縦方向の繰り返しをなくす
この順番の様子。
あまり使わない言葉は覚えなくてOK
現場で使うのかなと思いきや、使わない言葉もある様子。
エンティティが記憶に残りにくい、なんとなく要素として捉えていたからそこまで深く覚えなくて良い。ということでありがたい。
早速課題を修正していこうかな
課題でツイッターER図作成があるので、ひとまず自分で表が作れるようにしたいと思う。 一回なんとなくで出してしまっているので修正項目が多い。
リストについてもなんとなくなイメージがある。要確認。
正規化ができないと設計できないよね
データベース使うWebサイトやアプリを作るなら避けて通れない・・・と思って、しっかり学習していきたい。
デザインやサイト・アプリの仕様は変わってもここは変わらず残るもの、デジタルタトゥー以上に残るものなので、しっかり学習していきたい。
うーむ。
