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

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

Base64.decode64がMarshal.loadできないと怒られている

ここまでやったこと

sinatraの練習だと思って、こちらの書籍に沿ってwebアプリの作成をもくもく進めた。

で、この書籍の7章、cookieの使い方でつまづく。

何をした?

人とおりやっていることと詰まっていることはteratailに書いてみた。 解釈が合っているのかは自信がないけれど、 なんせ自分でできる範囲のことは調べたけれどお手上げ状態。

teratail.com

そもそもMarshalやencode とdecodeについて

エンコード・デコード

クライアントとサーバーのHTTP通信のやり取りで、1回のみのやりとりをセッションという。 そのセッションを継続して行いたい場合というのは例えばネットショッピングをしたときなどである。

ログイン情報を保持しつつ、色々な商品のページにアクセスする。 商品を購入するときはさまざまな商品ページの情報を一つのアカウントに紐づけて通信履歴を保持しておく必要がある。 それをセッション継続という。

このセッションを継続する際にはセキュリティ面を考慮する必要がある。

すごく色々端折るけど、通信やり取りを安全に暗号化させてしたいよね、ということで本番ではSSL環境を構築する。

けれども。SSLの概念理解として暗号と暗号解読キーのセットで情報を読み取れるような通信環境にしたいですね、試しにやってみましょうか。 という流れからエンコード・デコードの話に進む。

tech-unlimited.com

読むより実際に使ってみたほうが早い。

Marshalデータとは?

docs.ruby-lang.org

考えられる問題・・・

多分ASCII文字じゃなくてUTF-8になってるのが問題かなと思っている。 ただASCIIに変換する方法を模索中。

しかもこれが解決策にならないなら「詰んだ・・・」ってなってしまうかもしれない。

もしくはsessiontest.rbcookie値がうまく引き継げていないかとも思い出した・・・。

ほんと詰まるとずっと詰まる

これは長期戦だなと感じている。 早く脱出したいな^^;

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

最近よく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の設計を考える

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

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

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がとりあえず行けたからだいぶ肩の荷降りた

 

 

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

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

 

反省点として

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

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

 

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

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

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

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

 

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

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

amzn.to

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

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

 

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

 

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

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

 

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

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

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

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

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

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

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

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

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


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

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

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

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

あと直す箇所

重複というか、条件分岐を似た内容で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だった

引き続き沼

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

検証①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コマンド わかりかけたのに終わりが見えない・・・( ; ; )

長すぎるんですがー

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

課題点

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

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

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

元設計

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の中身の条件分け格納は設計途中でメソッド呼び出しを、と思ってる。

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

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

感想:めげそう

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

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

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

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

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

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

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

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

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

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

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

こうしようかな。

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

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