ヌンタコのプログラミング学習ブログ

フィヨルドブートキャンプ37期生

Web3とNFTの仕組みと何が流行ってるのか？

Web3

最近よくWeb3とNFTという言葉を聞きます。

 

 

そもそもわかってないので、しかも横文字なので、わけわかめでした。
が、なんとなく仕組みと繋がりが見えたのでメモっておく。

 

まずWeb3とは？


これまでWeb2とか出てきてその流れで3がでた。スプラトゥーンみたいな、アップデート的な感じで捉えて良さげ。ただWebは中身が色々違う。

 

これまで情報がYやGのサーチエンジンの最適化▶︎ターゲット層にフィットした広告・マーケティング▶︎それって情報が一箇所に搾取されて独占状態かつ中央集権的じゃないっすか？　と技術高い系の人不満。

 

とまあこんな感じで、政治云々で例えると、
🐙：「地方分権がデジタルというかネット社会でもおきつつあるってイメージ？」
友達：「うーん、そもそもそれでも県とか市による中央集権になるよね？」
🐙：「なるほど・・・じゃあもっと末端にも参画できる機会を？的な」
友達：「そんなイメージでとりあえず大丈夫🙆‍♀️」

 

Web3の背景はこんな感じで、情報の一極集中搾取を避けたいし、全てがそこに集約されてしまうとコントロールされてるよね？という問題から。


情報操作により傀儡化されるのを個人レベル・コミュニティレベル・国家レベルでも避けていきたい。ということから。

ふんふんなるほど。すっごい共感。

 

じゃあ仕組みは？

 

基本的には2点。

 

大量のデータを複数個のパッケージングして個人なりコミュニティなり起業単位でもつ。その大元の大量データのまたパッケージングしたものを他の人も持ってる。


そのパッケージ内部で他の人と重なる部分ができる。要は鎖のごとく共有している情報をそれぞれが持つことと外部に見える化、開示していることで改竄されないデータになっているというイメージ。

 

DBのリレーショナルが効かない状態のデータと言えば良いのか、誰かがとあるデータに変更を加えた（仮に改竄としよう）としても、他の人のデータに影響を与えない。

 

なのでやろうとすれば他の人の同じデータベースと整合性取れないのですぐに、「オタク、なんかいじりました？」ってなる。

 

ブロックチェーンと名前がついているので鎖のブレスレットのイメージでしたが実際はマインドマップのような状態で繋がってるイメージ。

 

そしてNFTとの関係性は？


ほんとね、ピンと来なかったのがここなんだよね。

インスタグラムで出てくるNFTは投資や株、仮想通貨の類で儲かるよ〜なイメージで投稿が流れてくるから、他のネット記事を見てもピンと来てなかった。

 

ここで自分の中でバイアスがかかってましたね。
インスタ見た直後、
・NFT▶︎投資系の新しいやつ？
ネット記事見て
・NFT▶︎なんかWeb3をつかってうんたらかんたら・・・

 

？？？？ってなった笑　あまりにも先行イメージと乖離があってリンクしなかった。

 

友達に聞いてみた


上記のことを友達に聞いてみた。聞いたことはあるけどわからないって言ってて、取り合えずネット記事読んでもらったらすぐにわかったぽい。IT知識あるのと変なバイアスかかってないのですぐに噛み砕いて教えてくれた。

 

NFTが注目された背景として


これまでツイ民などの絵描きさんはデジタルコンテンツだとパクリ・コピーされまくる。損をしていたと。まあ著作権がガバガバで保護されてねーやん！という電子データには問題があった。魂を込めた創作物を、金儲けのために努力もなしにコピーして販売する輩がいてなんだか虚しく悲しく憤る。というのをネット絵師さんは感じていたそうな。

 

じゃあこれがオリジナルでコピー品ではない証明をネット上でできれば良いのでは？
ということからWeb3の技術が注目された。

 

唯一無二を証明するNFT
デジタルな創作物に対して、
・この人が
・この日に
作ったことを
・第3者が
・その事実を
・証明するよ〜

 

ということがWeb 3のブロックチェーン技術で可能なんだそう。

それはいいね！👍

要はこの証明書が発行できることで、アートとしての取引が可能ともなる。
この絵は一枚しかないんだよ、やっと落札したんだよ。という絵画オークションがデジタルアートに対しても可能となる。という素晴らしい技術であると。

 

そういったことが転じて投資対象になってることもこの流れからインスタでNFTを投資対象として紹介している投稿が流れている。
というかんじ。

 

この中間付近の流れがすっ飛ばされてたので繋がりにくかったけど、よくわかった。
なので、NFTによってデジタルアートの購入ができることは、大富豪が金やアートに資産を変えることにデジタルアートも加わる
持っているデジタルアートをオークションに出すこともあるだろうって考えるとメルカリの逆が起きるのではないかな？

 

メルカリの逆っていうのは勝手に考えたのですが、新品で買ったものをAさんがメルカリで売る。それをBさんが安く買う。さらにBさんはいらなくなって中古の中古としてさらに安くCさんに売る。これを繰り返すことで価格の下り坂になる。ただNFTはその逆で、取引を繰り返すことで利鞘を得るんだろうな。と。売って買ってを繰り返す。

 

でも作品がでたタイミングでその将来性なりニーズなり、熟知した上で参入しないと逆に損をするだろう。アートとしてではなく投資対象として考えるのみであるならば。


そんな考えです。

 

やってみなよの一言

友達は「なんかあれも描いて出してみたら？」ということで、一つ試しに出してみようかなとも思う。

OpenSeeってとことかNFTの取引できるプラットフォームは色々ある。個人でも全然参入できるし、ブランド価値が認められ出したら徐々に値を上げていくことで副業なり専業になったりする。

 

とのことで、アウトプットは些細なことでもいいからしたほうが良いですね。

 

参考：

https://www.ecbeing.net/contents/detail/318

 

URIの設計を考える

URI設計 プログラミング学習

丁寧に学習しようと決めたのでかなりスローペース。

とりあえず基本ルールなどを学ぶ

https://qiita.com/NagaokaKenichi/items/6298eb8960570c7ad2e9

たちまちはこんな設計のサイトに遭遇。

そしてHTTPメソッドに関してはこれらのどれに当たるか、リソースがわかりやすく明示されているURIを設計する必要があると。

httpメソッド 何をするの？
POST 対応するURIをリクエストし、リソースを作成する
GET リソースを照会して、当該ドキュメントの詳細情報を取得する
PUT 当該リソースを変更する
DELETE リソースを削除する

そして基本ルールとして、

  • アンダーバーは使わない
  • 小文字でお願い
  • ファイル拡張子は含めない

などがある。

インターネット層

階層 どんなのがある？
アプリケーション層 HTTP,NTP,SSH,SMTP,DNS
トランスポート層 UDP,TCP
インターネット層 IP
ネットワークインタフェース層 イーサネット

ステートフルサーバーとステートレスサーバー

ステートフルサーバーな状態

この前こんなことがあった。ランチを食べにちょっとおしゃれな注文式バイキングのところに入ったら60代ほどの女性2人がオーダーしていた。

ディスプレイに20種近く並ぶおかずを自分で5つ選びワンプレートに盛り付ける。

A：「私これとこれと・・・。」 B：「私はこれとこのカボチャのやつと」 A：「それからこれも！」 B：「やっぱりさっきのカボチやめて，こっちに」 A：「それからこれと・・・アイスコーヒーと，あと何品だっけ？」

・・・

いっぺんに言え！

てなる。

これがステートフルです。

途中の状態をサーバが常に覚えてないといけない。

ステートレスサーバーな状態

同様の状態で奥様方をステートレスにしましたら，

A：「私はこれとこれとこれ，あとこれとこれ。そしてカフェラテでお願い。」 B：「私はね、これとこれ、あとこれ。そしてこれとれ。アイスコーヒーをお願いします。」

一つの会話ですみますね。

提携文に沿って1クライアントから注文を全て受けるイメージ。 一発で言ってくれるのでサーバはアプリケーション状態を保持しておく必要がない。 便利！

ただ欠点もある

ステートレスの欠点はパフォーマンス低下が挙げられる。 理由としては、 - 送信するデータ量が多くなる - 認証など、サーバに負荷がかかる処理を繰り返す

アプリケーション状態を保持しないということは全てきっちり承るよ、だからその分は一回の送受信が大きくなるから、クライアント数が多いとしんどいな〜という印象。

HTTPって何？

HTTPメソッドではクライアントが行いたい処理をサーバーに伝える任務がある。

8つあるけど前に主要な4つは書いたので省略。

前回の記事の続きで細かいところを見ていくと、

POST

GETに次いで利用頻度が高いメソッド。 代表的な機能は、子リソースの作成。

#リクエスト
POST /URIの直下のディレクトリとしてこの名前で作成してね HTTP/1.1
HOST: ホスト名.com とか
Contents-Type : テスキトなのか画像なのかなんなのか

内容物をここに書くよ

こんな感じで子リソースを作ります。

あああ、ツイート作成ってこんな感じなのかーとなった。

またデータの追加や他のメソッドでは対応できない処理もできるのでPOSTは結構使うみたい。

ER図を書くときに参考にしたサイト一覧

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

参考サイト

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

itsakura.com

http://paso-q.hiho.jp/doc/data/06111312121.pdf

https://academy.gmocloud.com/know/20160425/2259

外部キーってなんぞや？

medium-company.com

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

drive.google.com

便利なツール群

the.postalk.app

draw.io

前の職場で一部使ってた。でもデータベース作ることで使ったことなかったでちょっと新鮮。

wc.rbがとりあえず行けたからだいぶ肩の荷降りた

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

 

 

疲れた、ホッ。が着色なしの感想です、ハイ。

調べようにも逆引きサイトを最後にやっと見つけたくらいで、ググり力は上がりましたがやっぱり・・・疲れた。

 

反省点として

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

`map`メソッドがうまく使いこなせてない。実用例とか試しに使うことはあったけれど、`変数.map`でその変数に処理した新しい内容を上書きするのが最初イメージしにくかった。

 

ということでまた復習が必要なメソッド。

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

`ホニャララだったら ? 真だったらこれして : 偽だったらこれして`のこれは、

**〜だったら**の時のそれぞれの内容はどのくらいコンパクトだったら三項演算子内部に入れてもいいとかあるのでしょうか・・・。

 

わからないので、また聞こうかな。

そしてこれも読んでみたい。

amzn.to

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

共通項目をコンパクトにして重複をなくして。
リファクタリング沼

 

可読性のコードでかつ修正や変更のしやすいものって、経験で培われると考えているので自分での現状の最適解が現役の方からすると最適解じゃなかったり。

 

ただフィヨルドの方針上「ヒント」で「自分で考えましょう」で解答は突破するまで出さない主義なので、言い換えたり読み替えたりメソッドを実験的に使ってみたりでトライアンドエラーしないといけないわけで。

頭ではロジック的に考えられて図にも落とし込めるけれど、
それに対して自分の・・・プログラミング知識、語彙力などが乏しいのでイメージでは「手順はわかるけれど、使えるクラスやメソッドが何かあるの？」という状態。

 

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

前職が畑違いのマグネットメーカーだったので（私農学のバイオ出身です）、入社した時のことを思い出した。

経験者と未経験者の間の言葉の選択が異なるから合致しないという感じ。

会話してても聞きまくらないとどこのこと指してるのかわからないという感じ。

おおおーこれか。久しぶり。

でも前職でも自分が教える立場になると当時との逆パターンで違う感覚が込み上げてきた。

「ここまで追いついてこいよ」的な。自分で俯瞰しても昭和感ありありだなあ笑

でも入社したての頃は月に数回は大学の図書館で仕事の内容勉強してたかな。レゾルバとか周波数応答特性とか磁性体関連を満遍なく〜

磁場解析屋になったけど評価方針にはらわた煮えくりかえって辞めたわけですが笑


プログラミング界隈はベンチャーだし、個人主義でも環境を選べば自分の力量でなんとかなる、何より特殊な設備いらないのがいいですね。
夢があるなーと常々思う。

wcコマンド　修正_2回目の判断をなくす

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

とりあえずコンパクトにリファクタリングできてきたものの、まだだめらしい・・・

心折れかけてるけど考えてみる。

あと直す箇所

重複というか、条件分岐を似た内容で2回しているのでそこをなくすのが必要みたい。

ということで、現状は、 input_contents = ARGF.argv : [$stdin.read]

としているけれど、これだと前者は［ファイル名複数要素］、後者は［ファイルの中身1要素］という状態なので、これを下記のように二次元配列にする。

[[ファイル名 , ファイルの中身]]

なので二次元配列の［0］を使うか、［1］を使うか考えていく。 ただ、後者の標準入力の場合は［nil , [ファイルの中身]］で十分であるが、前者の場合は ファイル名とファイルの中身をセットにして配列を作る必要がある。

[[ファイルA , Aの中身],[,],[,]…]

と組で配列を作る必要がある。 なので，前者のようなファイル指定の時の処理分岐は，

どこまでがカンニングがわからないよね

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の使い方はまた見直さないとな，と気づいた。

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

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

引き続き沼

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

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

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

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

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

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

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

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

文字列で丸ごと扱うと、

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

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

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

input_contents = ARGF.argv #ファイル指定時
  1. 対象データの格納変数としてinput_contents準備
  2. ARGF.argv : $stdin.readこのどっちかが入る
  3. ファイル指定 => Array、標準入力 => String

  4. if input_contents = Array => ファイル指定の時の個々の処理

    • each分の中で配列値をreadあるいはFile.read(配列変数)する
    • readしたものに対して行数、文字数、バイト数
    • ファイル名出力
    • ★

  5. 標準入力の時の処理

    • 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(変数) => 配列が対象

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

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

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

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

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

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

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

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

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

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

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

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

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

こうしようかな。

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

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

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

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

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

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

ペアプロたのも〜

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

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

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

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

ただ・・・

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

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

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

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

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

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

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

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

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

でも言えることは、

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

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

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

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

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

wcコマンドの指摘事項

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

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

  • 一回作って放置して・・・

  • 直してまた期間が空いて・・・

  • 💡！

ああそうです。

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

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

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

わかったこと

docs.ruby-lang.org

docs.ruby-lang.org

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

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

なるほど。

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

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

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

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

なので、

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

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

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

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

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

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

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

直すべき項目

  • 先ほどのメソッドで一つの変数で扱う
input_contents = (!ARGF.argv.count.zero? ? ARGF.argv : readlines)
  • 標準入力かファイル指定の値か変数を識別する処理が必要

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

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

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

🐙：「ですよね(💦)」

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

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

うーん。

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