input_contents.each do |content|
    content[1].each do |file_data|
        #ファイル内容の集計値の出力処理
　　　#複数の場合はトータルを集計
    end
    content[0].each do |name|
        #ファイル名出力の処理
    end
end

こんな感じでおそらくいるのかなと。

リファクタリング

コンパクトにする，他の人が読んでわかりやすくする，修正しやすいようにする。という認識ぐらいでしたが，実際にビフォーとアフターをガッツリ見たことがないので「ふーんそうなんだ」くらいの印象でした。

てことで調べたらこんな記事が出てきまして。

postd.cc

it-trend.jp

すごく腑に落ちた感じです。

バグの連鎖はキツいな・・・

今プラクティスで作っているものは単純な処理だけだけど，Webアプリを外部向けに作るとなるとバグももれなくくっついてくる。機能追加でアップデートするとまたもれなくバグが発生する。

バグを修正したら新たなバグを生む・・・という恐怖の連鎖。

プログラマーという肩書きだけでなんかスマートで今どきで，オフィスがオシャレで自由で・・・という幻想抱きやすいけど，プログラマー＝忍耐力いるなあという印象になった。忍耐忍耐・・・。

私自身農学部出身ですが、2回生ごろまでは頑張っておしゃれして登校するものの、卒論や就活、資格試験にバイトとみっちり入れた頃はオシャレ着→ジャージ＋最低限眉毛のみ描く。という状態になってたな。多分ゴリゴリコード書いていくとこんな感じになりそうだなあ。

もう今が既にそんな感じかもしれない。

さらに今朝修正しました

上記の直しに「1行でまとめられませんか？」と直しがヒント付きで返信きまして直す。

mapの使い方はまた見直さないとな，と気づいた。

2022-08-03

wcコマンドの続き　Arrayだと思ってたらStringだった

wcコマンドプログラミング学習

引き続き沼
- 検証①Stringで取得してファイル指定の時はそれを分割して配列化 => 処理
- 検証②ファイル指定を配列、標準入力は文字列として処理
設計案
使えそうなメソッドなど
参考リンク

引き続き沼

検証パターンとその課題を綴る

検証①Stringで取得してファイル指定の時はそれを分割して配列化 => 処理

対象データの格納変数としてinput_contents準備
ARGF.read : $stdin.readこのどっちかが入る
標準入力の場合とファイル指定時の合計値は一つの処理で完結する
ファイル指定の時の個々の

ファイル内容の処理結果・ファイル名出力はどうするか？　 <= ここが課題

input_contents = ARGF.read #ファイル指定時

これになった時、初回で.readしてしまってるので4.の処理をするには不向き。ファイル指定時のみinput_contentに対して、

input_contents2など異なる変数にARGF.argvを使う => 格納されない
input_contentsを二次元配列にする => 格納されない

同一コード内でARGFが使えるのは1回きり？

文字列で丸ごと扱うと、

ファイル複数指定時の処理
標準入力時の処理全て

これを一気にできるので良いと思ったけど、配列として初めから取得した方がよさそう。

検証②ファイル指定を配列、標準入力は文字列として処理

input_contents = ARGF.argv #ファイル指定時

対象データの格納変数としてinput_contents準備
ARGF.argv : $stdin.readこのどっちかが入る
ファイル指定 => Array、標準入力 => String
if input_contents = Array => ファイル指定の時の個々の処理
- each分の中で配列値をreadあるいはFile.read(配列変数)する
- readしたものに対して行数、文字数、バイト数
- ファイル名出力
- ★
標準入力の時の処理
- Stringとして処理する =>この場合★(ファイル指定時はArrayなので同一処理が不可)
- そのため、★同一処理を進めるならファイル指定(Array)=>ファイル指定(String)にする処理が必要？

6.★ => ファイル指定の際の合計値 - 5.で一緒にできたら良いけれど、Array => String問題がある変換するプログラムがいる - あるいは4.の処理each内部で集計して抜けたら合計値を出力するようにするか

設計案

上記のどれを取ればリファクタリングした、冗長的でないコードになるのか全部試す前に一つずつ設計してみる。これ以外の設計の仕方が思いつかない。

処理：A => ファイル指定、 B => 標準入力

仮設計①：ABどちらも文字列(`String`)として使う場合

仮設計①

input_contents = (!ARGF.argv.count.zero? ? ARGF.read : $stdin.read) 

#コマンドライン引数で指定した時に「ファイル名」ごとに中身を配列として分けるにはどうすればよいか？
#コマンドライン引数で指定した時に「ファイル名」をどう取得するか？

# 合計値の出力(ファイル複数指定、標準入力)

コマンドライン引数入力時に先に読み取ってしまうと、各ファイルごとの集計ができなそうなので却下。

仮設計②：AはArray,BはStringとして使う場合

仮設計②

input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : $stdin.read)

この場合はFile.read(変数)を使う必要がある。コマンドライン引数でinput_contentsに格納されたファイル名をeach文で読み込み、集計していく。 Aに対して、

ファイル名の配列をeachで取り出し
File.read(変数)で読み込み
改行数、ワード数、バイト数を集計
※複数の場合はここで合計値用の配列変数に集計していく※
集計後は上記とファイル名を出力

Aの複数の場合

上記の繰り返し出力が終わったあと、
合計値用の配列変数を出力

Bに対して、文字列として取得してるので以下で処理できる

標準入力を文字列で取得しときの処理

print "    #{content.count("\n")}"
unless options['l']
  print "    #{content.split(/\s+/).size}"
  print "    #{content.bytesize}"
end

仮設計③：ABどちらも配列(`Array`)として使う場合

仮設計③

input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : readlines)

Aに対して、

ファイル名の配列をeachで取り出し
File.read(変数)で読み込み
改行数、ワード数、バイト数を集計
※複数の場合:合計値を変数に格納していくdata_sum =[改行数,ワード数、バイト数]※
集計後は上記とファイル名を出力

Aの複数の場合

上記の繰り返し出力が終わったあと、
合計値用の配列変数を出力

Bに対して、

["ファイル名\n","ファイル名\n"...]の状態なので繰り返し処理の内部で改行を省く
同時にファイル読み込みをしないでcontent = ファイル名として
改行数、ワード数、バイト数を集計
合計値を変数に格納していくdata_sum =[改行数,ワード数、バイト数]
合計値用の配列変数を出力

共通部分はメソッドで切り出して都度呼び出すようにするべきか？

使えそうなメソッドなど

ファイル読み込み

変数.read => 文字列が対象
File.read(変数) => 配列が対象

コマンドライン引数か標準入力

ARGF.file => ファイル指定で1ファイルのみ格納　文字列、標準入力で#<IO:<STDIN>>が返ってくる
ARGF.argv => ファイル指定で配列で取得、標準入力の場合　空
ARGV => ファイル指定で配列で取得、標準入力の場合　空
readlines => ファイル指定で指定ファイルの内容を改行ごとに配列格納。複数だと全内容を1要素として格納、標準入力での出力 = 改行含めて取得 "ファイル名\n…複数" この文字を配列として改行ごとに格納
readline => 1行のみなのであまり使えない
STDIN.gets => ファイル指定では動作が止まる、標準入力での出力 = 先頭一つのみ取得"ファイル名\n" 文字列
$stdin.read => ファイル指定では動作が止まる、標準入力での出力 = 改行含めて取得 "ファイル名\n…複数" 文字列
$stdin.readlines => ファイル指定では動作が止まる、標準入力での出力 = 改行含めて取得 ["ファイル名\n"...複数] 配列として取得

その他

9.File.read(文字列) => 内容を読み込み

メソッド引用

.filename -> String :現在開いている処理対象のファイル名を返します。標準入力に対しては - を返します。組み込み変数 $FILENAME と同じです。

file -> IO[permalink][rdoc][edit] 現在開いている処理対象の File オブジェクト(または IO オブジェクト)を返します。

$ echo "foo" > foo
$ echo "bar" > bar

$ ruby argf.rb foo bar

ARGF.file      # => #<File:foo>
ARGF.read(5)   # => "foo\nb"
ARGF.file      # => #<File:bar>
ARGFが現在開いている処理対象が標準入力の場合、$stdin を返します。

引用： class ARGF.class (Ruby 3.1 リファレンスマニュアル)

参考リンク

qiita.com

sites.google.com

逆引きRubyあった・・・

2022-08-01

wcコマンド　わかりかけたのに終わりが見えない・・・（ ; ; ）

wcコマンドプログラミング学習

長すぎるんですがー

なんで終わりが見えない？課題点
- 課題点
- 元設計
どうすればいいか？
感想：めげそう
今後の日報こうしたいよね案（自分用）

なんで終わりが見えない？課題点

課題点

標準入力かファイル指定かというのを一つの変数で扱うと処理がコンパクトにできない？
データ格納の変数をどちらも一つで行うと、ファイル内容を読むかどうかで分岐できない
変数の中身をそれぞれで区別したい
出力部分を一つに管理

設計がよろしくない？と思われるので、ロジック図でまた整理するところからするしかないかな。 PRのコメント指摘内容がわかったと思ったら、かなり設計し直しと言う感じで結構きつい。

放置してた期間も長いだけにwcコマンドは２ヶ月くらいかかってしまってる。きつー

元設計

wcコマンド冒頭の設定

require 'optparse'

options = ARGV.getopts('l')

input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : $stdin.read)
file_information = []
total = [0, 0, 0, 'total']

標準入力の際は、文字列で引っ張ってくると処理しにくいので切り分けて改行をとって、配列にしてから、改行数、単語数、バイト数を処理している。

ただ、上記でもあるように - 標準入力 => 文字列としてファイル内部は参照せずに集計 - ファイル名指定 => ファイルの中身を集計

という動作が異なるのでどう処理を切り分けて重複箇所を防ぐかが設計なんでしょうが、うーんってなってる。

どうすればいいか？

ARGF.argv と$stdin.read を使うとクラス分けできる
File.read()を使う場合とそうでない場合を作る

ifの指定がうまく効いてないところがちょいちょいあるんだよなあ。

input_contentsの中身の条件分け格納は設計途中でメソッド呼び出しを、と思ってる。

あとは.classかof_kind?()使って分岐させることも必要かなと。

ちょっと具体的な設計までまだ掴めない。

感想：めげそう

一言で言うならめげそう・・・昨日から3時間程度の学習時間ですね。リファクタリングして冗長的表現や重複箇所を削って最適化する作業、は設計を一から組むこともあるんだなーと当たり前ながら本当気が遠くなる。慣れたら＝経験重ねたらできるところもあるでしょうが、ないからね。

やっぱり逆引きできないのは不便だなー逆引きできたらどんなに良いことか・・・

と思ったらやっぱりあった。ただレビューが★４切ってると「うん？」ってなる。

レビュー読んで「うんうん」ってなった。わかっている人が書く文章とわかってない人が苦労してわかる人になった時の内容のわかりやすさって違いますよね。ってことを指摘してるのかな。

問題の解法や途中式でところどころショートカットしているようなイメージの書籍なのかな。考えて読め、そしてこの一冊で全網羅じゃなくてネット検索と複合的に使いなさいよ。的な一冊なのかな。

そしてまさかのこんな本見つけた！

フィヨルド卒業したらやってみたい気もする。（気が遠くなるからここは「へ〜面白い」程度で留めよう）

奥が深いこと学習するときは狭く深くやらないとあれもこれもで進まなくなってしまうので注意ですよね。

今後の日報こうしたいよね案（自分用）

日報がここでも書いてフィヨルド内でも書いてってするのが正直面倒になってきたので、

ここで内容を書いて
フィヨルドの日報にははてぶの記事をリンクとして貼る
日報には見出し・はてぶリンク・学習時間を記載

こうしようかな。

転記が二度手間なので・・・

とりあえず今日もお疲れ🏖

2022-07-27

wcコマンドをrubyで作る再提出

wcコマンドプログラミング学習

あまりにも指摘事項に対してチンプンカンプンだったのでペアプロお願いしました。鉄は熱いうちに打てということで、分かったことと今後やるべき内容をまとめておこうと思う。

※チンプンカンプンって変換したら珍紛漢紛って出てきた。由来これなのかしら。

ペアプロたのも〜
- なんで苦手になってるか過去の体験に遡る〜
- 何でこんなに言われないかんのか当時考えた
wcコマンドの指摘事項
- これとこれ共通化できますよね？
わかったこと
- リファレンスは逆引きできない
直すべき項目

ペアプロたのも〜

画面越しにため息が聞こえてきそうな雰囲気も感じつつペアプロをお願いする。 ※実際ため息したかは知らない、9割が被害妄想です。
ペアプロしました

実際見てもらう、アドバイスもらうのは苦手意識がついています。

なんで苦手になってるか過去の体験に遡る〜

というのも６年ほど前にjavascriptを勉強していたんですが、まだ大学出たばっかりで右も左もわからんし、具体と抽象の質問で考えるとかなり抽象的に質問したのはわかる。

ただ・・・

当時テラテイルの粛清とも言えるアドバイスはほぼほぼマサカリに思えて。質問するたびに怒られ、ググれカス言われる（実際ここまで言われてませんが婉曲表現好きな人いますよね）

そしてヤフ知恵に逃げ込んでも同じ感じの方が多い。他の質問見てもわざわざ返信欄に「はあ・・・だから、」と付け加えている。

わかる立場になるとわからんこともないけど、あんまりじゃない？そうでもない？ここは初学者ぴえんポイントのはず。

何でこんなに言われないかんのか当時考えた

費用負担が安く学べるプログラミングなので、先駆者から見たら

夢見がちな若者に正義の鉄槌
GRIDないやつに出る杭を打とうかね
誇大広告から夢見がちなやつにリアルを教えてやろう
シンプルにもうちょっと調べ学習進めて知識持ってから聞こうぜ？（抽象→具体）
察してもらうようなテキストコミュニケーションやめれ

のどれかor複合で感じているかもしれない。

という過去の経験からちょっとテキストコミュニケーション震える。ブルブルブル・・・

自分もこういった過去があったので、身近な人に「プログラミング学習って私でもできる？」と不意に聞かれると返答に戸惑う。

でも言えることは、

仕事が効率的に自分で順序考えてできてたなら素地はあるのでは？
今後も使う機会があるのか？
プログラミングで何がしたいの？
かける時間と費用はこのくらいだけどOK？
続けられそうです？？

素地×時間×費用×気合い（継続力）

が高ければ高いほどできると思ってる。ただできる≠習得ではない、プログラミング学習＝青天井

という過去があるので、ちょっと緊張はする。

~~そしてペアプロ前に大体昼寝してるので、寝ぼけてることがある（すみません）~~

wcコマンドの指摘事項

これとこれ共通化できますよね？

うん、何となくわかる。ただ、自分が何でここ分けたのか思い出すのに10分ぐらいかかる。

一回作って放置して・・・
直してまた期間が空いて・・・
💡！

ああそうです。

🐙：「確か、ファイル指定と標準入力を見分けるのが必要かと思ってif文で冗長的になってました。」

メンターさん：「なるほど。でも・・・」

ここで指摘が入り、具体的なアドバイスをもらえた。

わかったこと

docs.ruby-lang.org

このメソッドをうまく活用しましょうということ。

文字列を返すreadと$stdinをうまく組み合わせて使いましょう。と

なるほど。

リファレンスは逆引きできない

何で今回こんな行き違いというか、わからない状態が続いたかというと、

最適なメソッド検索がわからないから起きたと思ってる。結局標準入力の仕方をreadlines以外知らなかったんですね。

実際どこに何があるか、読書のごとくリファレンスを見ているというよりかは、何か必要性があったときに探してみる。方が強い。

なので、

こういう処理をしたいのでこういうメソッドが欲しい
「なんかワード」検索する
それっぽい記事が出てくる
記事に書いてあるメソッドをリファレンスで調べる

大体この順序なので、この一つの工程に対して一つのメソッドしか知ることがない歯痒さがある〜紙の辞書なら前後左右の事柄が視界に入るから一個調べても同時に何個も知識が入るけど、 4.でピンポイントに調べるから一つしか得られない。

結局リファレンスを隅々見ろよと言われたら、そういうもんなんですね。としか言えない、ね。

それに逆引きできても日本語の表現なんてわんさかあるからヒットするまで頭の中で言い換え＝変換を繰り返してグーグルさんにお願いするしかない。「〜　ruby」「ruby 〜」「メソッド　〜　ruby」・・・とか何回検索したことか。

でもこの地道な作業を乗り越えた先に先駆者はいるのかしら。
それとも新卒入社で入ってOJTで先輩がきっちり現場知識叩き込んでくれた人々なのか。

わからないけど、マサカラナイでといいたい。

この検索作業は地味にストレスですね。いい方法求む・・・

直すべき項目

先ほどのメソッドで一つの変数で扱う

input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : readlines)

標準入力かファイル指定の値か変数を識別する処理が必要

一つの変数（input内容）に対して同様の処理を行うことでリファクタリングしてるのであれば、この識別が必要になるよね。

🐙：「こことこれで〜・・・仮にディレクトリ内部に1つしかファイルが存在しない場合の標準入力とファイル指定の変数に対する識別はどう・・・？」

メンターさん：「・・・それを考えるのも課題なので・・・。」

🐙：「ですよね(💦)」

学校のテスト中に先生に質問して返される時と同じ現象が起きた。

なので変数に与えた内容が標準入力でもファイル指定でも同様の処理で済むように工夫が必要ということ。そして考えないといけないのは上記の識別方法というところ。

うーん。

一晩寝かすか。（やれよ）

2022-07-25

RESTの考え方を理解する

Webアプリケーション REST

RESTってなんだ？
それぞれの役割

RESTってなんだ？

Webサービスの設計モデルらしい。REST化したWebサービスはHTTPメソッドでアクセスするとデータの送受信をクライアントとサーバーサイドでやりとりしてくれる。

色々あるアーキテクチャスタイルのうち、クライアント／サーバーの設計が有名である。そのうちのRESTはアーキテクチャの中で色々と制約をつけてコンパクトにしたもののイメージ。

そしてRESTは複数のアーキテクチャスタイルから組み合わせて構築した複合アーキテクチャスタイルを指す。

RESTアーキテクチャの構成

ステートレスサーバー
キャッシュ
統一インターフェース
階層化システム
コードオンデマンド

この1~4項目に即したWebサービスはRESTfulと言われる。

リソースとは？

Web上の名前を持ったありとあらゆる情報このリソースを識別するにはURIを使います。

URI

統一リソースの識別子これにより全てのリソースを一意に示せる。

URIが備える、リソースを簡単に指し示せる性質はアドレス可能性と呼ぶ。リソースに対して名前がついていて、適切な手段でアクセスできる状態

http://blog.example.jp/entries/1

これをそれぞれ分解すると・・・

URIスキーム：http 👉利用プロトコル
ホスト名：blog.example.jp 👉DNS
パス：/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

引用：

2022-07-24

ツイッターのER図を作る

プログラミング学習データベース

正規化がとても難しい
- 正規化とは？
ひとまずpostalkでざっくりリスト化
- 最初こんな感じで考えた
- でもテーブルごとにID付与しないとだめだよね・・・？
draw.ioでER図作成
課題とモヤモヤ

正規化がとても難しい

正規化については、動画と著書で6割理解と後残りは実践だと思ってる。

正規化とは？

表の横方向の重複整理
テーブルごとの縦方向の重複整理
1対nの関係で切り出していく

第２正規化がまだいけるんじゃない？の自問自答で煮詰まる。

ひとまずpostalkでざっくりリスト化

最初こんな感じで考えた

でもテーブルごとにID付与しないとだめだよね・・・？

ひとまず、リスト化はここまでで作ってみる。

draw.ioでER図作成

draw.ioのsoftwareを選ぶと使いやすい。鳥の足とか用意してくれてる。

1対nの意識が難しい・・・

課題とモヤモヤ

まだ正規化できるんじゃないか？やっていいのか？という迷い
特に画像のテーブルを作った方が良いか？
ハッシュタグはプロフィールやツイートごとのテーブルにそれぞれ付与でいいかな？

重複するようなものなのか、煮詰まると正確に判断できなくなってくるなあ。

参考サイト

基礎知識として必要そうなイメージ

外部キーってなんぞや？

実際にER図を設計するときの流れ

便利なツール群

draw.io

反省点として

mapがまだ使いこなせないなあ

三項演算子の中身ってどこまでコンパクトだったら良いの？

最適な設計は繰り返しやってみるしかないか

前職の記憶が走馬灯のように

あと直す箇所

さらに今朝修正しました

引き続き沼

検証①Stringで取得してファイル指定の時はそれを分割して配列化 => 処理

検証②ファイル指定を配列、標準入力は文字列として処理

設計案

仮設計①：ABどちらも文字列(String)として使う場合

仮設計②：AはArray,BはStringとして使う場合

仮設計③：ABどちらも配列(Array)として使う場合

使えそうなメソッドなど

ファイル読み込み

コマンドライン引数か標準入力

その他

参考リンク

なんで終わりが見えない？課題点

課題点

元設計

どうすればいいか？

感想：めげそう

今後の日報こうしたいよね案（自分用）

ペアプロたのも〜

なんで苦手になってるか過去の体験に遡る〜

何でこんなに言われないかんのか当時考えた

wcコマンドの指摘事項

これとこれ共通化できますよね？

わかったこと

リファレンスは逆引きできない

直すべき項目

RESTってなんだ？

RESTアーキテクチャの構成

リソースとは？

それぞれの役割

1 ステートレスサーバー

2 キャッシュ

3 統一インターフェース

処理結果に対する返答のステータスコード

4 階層化システム

5 コードオンデマンド

正規化がとても難しい

正規化とは？

ひとまずpostalkでざっくりリスト化

最初こんな感じで考えた

でもテーブルごとにID付与しないとだめだよね・・・？

draw.ioでER図作成

課題とモヤモヤ

仮設計①：ABどちらも文字列(`String`)として使う場合

仮設計③：ABどちらも配列(`Array`)として使う場合