react

ReactRouter触ってたらよくわからなくなってきた。

どこまでStatefulにしたらいいのかもうおじさんわからないよ。

やっぱ闇雲に実装しすぎてる感じがするんだけど、何を学べばいいんだろうか・・

 

とりあえずそれとは別にコンポジション・・というかAdapter使って一覧の表示を1つのコンポーネントでやってみたのはわりとうまくいった。でも正しい方法なのかわからん。

Statefulなコンポーネントは継承と集約どっちがいいんだろ。やっぱstate持つ場所がネック・・

分岐とか反復とか

前々から考えてたことに折り合いがついたので二本目。

 

処理というのは変換のことだ。

つまり、「AをBに変える」という類のものが処理とか計算と呼ばれる。

 

そこで分岐処理と反復処理を見てみると、前者は出力が複数あり、後者は入力が複数ある。

つまり、分岐処理は「Aを、BやCに変える」という処理なのに対し、反復処理は「AやBを、Cに変える」という処理だ。

ここに順列処理と分岐、反復処理の違いがあるんじゃないかと思う。

組み合わせたら「AやBを、CやDに変える」みたいな両方複数の処理も作れるから、順列、分岐、反復の3つまでしかないのだ。

ReactとFluxとValidationと

Reactのバリデーション試してたけど、結局Action投げてStoreでバリデーションするのがいいのかなぁ。Railsみたいにstateでerrors管理しとけばフォームがなんとかしてくれる感じで。ただerrorsが生のオブジェクトのままだからisValidどこでやろうかな。Map拡張してもいいけどどうか。

あと最近はただの関数としてComponent定義するのが好み。たぶん合ってる。

gist.github.com

ペンは走る

いつも勉強するときはA4無地のルーズリーフが欠かせない。

今日はペンが走ってたけど、作りたいものがないからソースコードは全然書けない。だからとりあえずDOMの復習とかしてた。DocumentとElementがEventTargetとNodeのインタフェースを持ってるからEventListener登録したり、子どもを検索したりできるんだ、ってとことか。

ここのところは問題を解決するために使えるものを人も物も金も知識も行動もとにかくリソースとみなして考える思考を試してて、問題解決ってのはそもそもリソースを得るためにリソースを使って、リソースを使うためにリソースを得る行為だからリソースによって価値が決まってて、それがPDCAの計画とか評価にも使えるんじゃないかとか色々。

とりあえず作りたいものがないときはリソースをとにかく稼いで、リソースを使いたいときのための貯金と、スコアアタックとしての楽しみを見出すのがベターなのかもしれない。とにかくお金稼ぐとか資格取るとかいうパターンだ。お金も資格も意味があるかどうかは置いといて、明確な報酬が得られるのはいい。それ自体に暇つぶしとしての価値がある。

インタフェース

一昨日あたりから設計について勉強してるんだけど、結局のところSOLID原則が指してるのが可換(低結合)と隠蔽(高凝集)だって記事を読んでなるほどなってなった。

そう考えると、BootstrapやMaterial UIの意義もやっぱインタフェースにあって、HTML側とCSS側をそれぞれ隠蔽して、可換にしてるんじゃないか。BootstrapはCSS側だけど、それをHTML側からやってるのがMarkdownで、もちろんすべてのHTMLを吐き出すわけじゃないけど、どういう要素に対してどういうタグが付けられるのか、ってざっとインタフェースで決まってるからCSSはそのとおりに作ればいいし、Bootstrapだったら先にCSSのインタフェースが決まってるからHTMLはそのとおりに作ればいい、ってまさに可換なんだ。おそらくHTMLとCSSを作った人が目指していたような責任の分界ができてる。インタフェースをチーム内だけじゃなくOSSで公開したところに意義がある。

で、SOLID原則はオブジェクト指向というよりもむしろモジュール化全般に通じてて、機能を集約して機能を作る、機能は機能の集まりで機能から機能ができてる、という状態。それが結局はプログラミングでもなんでも、問題解決のための資源を作るためのやりかたなんじゃないか。プログラミングは問題に対する機能を詳細まで詰めて、詳細を元の機能のレベルまで抽象化しなおすのが設計の役割だ。そうしないと理解するのが難しいし、使いにくいから。そうなると継承はモジュール化よりもむしろ詳細を作りこむ、実装の方に近い。だから汎用性の低い継承よりもモジュール化向きの委譲使っていこ、って感じでGoとかも作られてるっぽい。

このあたり、設計はむしろプログラムというより人間の認知のためだと考えたら、ドメイン駆動設計で問題領域そのものを抽象化して理解しやすくすることには一定に価値があると思う。ユビキタス言語はチーム内で共通の名前をつけて、それを人と人との間のインタフェースにしてるんだし。とにかくインタフェースだ。ルール。

デザパ

今日は牧場行ってきた。

ヤギとかウシとかヒツジとか。ヒツジは近くまで来てくれなかった。あとソフトクリームがうまい。

そのまま高知まで行って大回りで帰ってきたけど、遠すぎる。疲れた。

あ、誘う友達がいないので家族とです。

 

出発したのが10時くらいだったからそれまでにちょろっと勉強。デザインパターンの見直ししてた。それもGoFから。

このあたりの設計とかはどうやって勉強したらいいのかなぁ。哲学の勉強してたときの知識がある程度役に立ってるのはある。

 

コンポジションとかモナドとか、結局は状況=Contextを表現してんのかな、って感じ。

Yamada = new Person("YAMADA")

new Student(Yamada)

だったら「生徒としての山田さん」を表してる。「山田さんが生徒である」という状況。

Student extends Person

Yamada = new Student("YAMADA")

だったら「山田さんという生徒」を表してる。こっちは物。

状況によって「物を与える」が「物を贈る」になったり「押し付ける」になったりするのと同じように、「人」が状況によって「生徒」になったり「教師」になったり「息子」になったり「上司」になったりする。その違いを明示するのが「命名」なんだろう。状況によって「モノ=Object」も「コト=Behavior」も働きが変わる。意味が、変わる。

あと状況というものはそれだけが存在するんじゃなくて、周囲との違いから見つけられる相対的なものだから、生徒という山田さんがいたら別の人が教師をやってないと変なわけで、そのあたりの対称性というか、片側があったらもう片側もあったほうが理解はしやすいんじゃないかと思う。

プログラミングは機能を詳細に分解していく作業だからただプログラミングしてるとひたすら複雑化する。だから詳細をまとめあげて求めている機能の高さまでマクロ度を戻すのがカプセル化だ。コーディングとカプセル化は対立してて、求められる機能のために手段となる機能を見つけていくのがコーディング、いくつもの機能をまとめあげてひとつの機能のように見せる鍵になるのがカプセル化にあたる「命名」っぽい。そんな感じ。うん。

変数も関数も結局のところカプセル化であって、オブジェクト指向だけが特別なわけじゃない。オブジェクト指向の特別なところはむしろ機能を物として見るためのグルーピングかも。カプセル化の手段をひとつ提供してるだけなのか、捉え方を変えたという意味で大きな進展があったのか。継承とか集約とかはおまけ。

おべんきょ

せっかく会社休みになったからまたちまちま勉強してる。

でも午前中にポモドーロを大きく進めてしまうと午後眠くなるからできれば昼寝したい。だいたい会社でも昼休みは寝てる。

 

今日は正規表現とかJSの公式ドキュメントの見直しして、設計の勉強に関数型の記事をいくつか読んでた。あとAirbnb Javascript Style Guideにも目を通した。セミコロンとか末尾カンマとか結局使うのが優勢なんかな。

その中でモナドって概念が出てきたんだけど、これって結局はインタフェースの決まったコンポジションってことなのかなぁ。モナドを生成するunitとモナドの中身に計算を適用するbindを持ってるだけで、何かを元にモナドを生成するとあとは全部同じインタフェースで使える、と。

FunctorとかApplicativeとかはまだいまいち。もうちょいがんばりましょう。

 

このへん参考になった。まぽよんさんにもマジ感謝👏

JavaScriptのモナド | プログラミング | POSTD

「モナドは象だ(Monads are Elephants)」日本語訳 — Japanese Translation of Monads are Elephants v1.0 documentation

箱で考えるFunctor、ApplicativeそしてMonad - Qiita