『よゐこのマイクラでサバイバル生活』を妻と観る。妻はわりと楽しそうに観ていた。
前に (2016-10-25 / 2016-10-27 / 2016-11-06 / 2016-11-30 / 2016-12-21 あたり) 遊んでいた『テラリア (Terraria) 』を思い出す。あれは妻がつまらないと、やめてしまったんだっけ……。ぼくひとりで遊ぶのも……とやめてしまった。
マインクラフトは 3D の時点で拒否されてしまうだろうな。念のため聞いてみたら、観る分には良いけど、遊ぶのは嫌だそうだ。
2017-W45 ふりかえり
2017-W45 をふりかえる。
2017-11 の目標
2017-W45 の目標 とその記事
目標。
記事。
- 2017-11-11 『 UNIX という考え方』を読んだ
- 2017-11-10 『エイプリルフールズ』を観た / 小さなたくさんのプロジェクトを更新する
- 2017-11-09 bouzuya/rally-cli-hs スタンプラリーの詳細の取得 / ベヨネッタ 8 章
- 2017-11-08 bouzuya/rally-cli-hs Data.* への抽出 / ベヨネッタ 6, 7 章
- 2017-11-07 『いかにして問題をとくか』を読んだ
- 2017-11-06 何をやっていたのか分からない日
- 2017-11-05 2017-W44 ふりかえり
ゲーム。ベヨネッタはゆっくり進んでいる。
読書。『 UNIX という考え方』と『いかにして問題をとくか』を読んだ。数学ガールの「参考文献と読書案内」からまた何か借りようかな。『型システム入門』は開いていない。
bouzuya/rally-cli-hs は export をすこしずつ進めている。
ぜんぶすこしだ。
つくったもの
2017-10-06/2017-11-12
すこしずつ……。
その他
股関節 (右) が治らない。
今日は親戚の結婚式に参加する。黒人がアメイジング・グレイスを急に歌いだしたり、シャンデリアが回転したり、寒い中白馬に乗って去っていく感じだった。全部どうでもいい。
仕事は一周してやりたいことへ戻ってこれている感じ。 CSS を書かねば。
読書のおかげかは分からないけど、学生の頃のような気持ちで居る。学生の頃というのが説明しづらいのだけど……。やりたいことはたくさんあるし、時間は足りない。だけど、過度に焦らず、どこか落ち着いた感じ。本来の自分のペースに近い気がする。もうすこし成果を出していける状態にも持っていけるはずなんだけど……。
来週も今週と同じ目標かな……。
2017-W46 の目標
『 UNIX という考え方』を読んだ
『 UNIX という考え方 』を読んだ。
はじめにまとめられており、それらの詳細を見ていく形になっている。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作する
- 効率より移植性を優先する
- 数値データは ASCII フラットファイルに保存する
- ソフトウェアを梃子 (てこ) として使う
- シェルスクリプトによって梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタとして設計する
個別に感想を書いていく。
小さいものは良い。そして、ひとつのことをやるものは良い。この組み合わせの話はほとんど「凝集度」の話だ。
大きいものは往々にして余計な・不必要なものを含む。小さくすると余計なものを含む余地が減っていく。小さいものを組み合わせれば、必要なものだけを選び、不必要なものを避けられる。この点で素晴らしい。一方で、小さいものを組み合わせるのは手間がかかる。この点にはあとで触れる。
試作するのは良い。「案ずるより産むが易し」だ。やったほうが早いことはある。それに試作で気づくことは多い。「人間による三つのシステム」として書かれてもいるが、だいたいのものは三回目以降で良くなってくる。この回数は経験則的で根拠がない。ただ、こなれてくるまでには時間がかかるし、つくりなおしもある。後発のほうが良くなる。
試作するのは良い……が、どれくらい早いと良いのかは難しい。「できるだけ」の線引きだ。特に気になるのが計画の有無だ。ぼくはここ一ヶ月のうちに『計画を立てろ (2017-10-27) 』という日記を書いた。大まかでも計画を立てたほうが良いと思う。これは正しい状態かを判断できるようにする第一歩だ。大きな計画のもとで試作を重ねるのは良い。大切なのは、詳細までは要求していないこと、試作を否定しないことだ。遠足のしおりには、歩行のための手順は書かなくていいが、目的地と予定時間くらいは書いてほしいだろう。
効率より移植性を優先する。効率については例の最適化の法則を引用すると良さそうだ。
「プログラム最適化の第一法則: 最適化するな。プログラム最適化の第二法則（上級者限定）: まだするな。」 - Michael A. Jackson
いろいろ事情が変わっている気はする。効率はマルチコア化が進んだあたりで変わっていそうだ。ぼく個人としてはそこまで効率を要求される状況にない。移植性は仮想マシンの登場や Docker などで変わっていそう。ぼく個人としてはアプリケーションは特定の環境 (たとえば Docker 内) で動けば良しとすることが多いように思う。もちろん原則として環境依存はしないように心がけてはいるけれど。
バイナリデータは必要なら使う。そうでなければ使わない。確認しづらいので。バイナリで効率を良くしないといけない状況にはまずならない。
梃子。まとめづらい。いくつかの話が混じっているように思う。
ひとつは「既にあるもの（ライブラリなど）を活かせ」という話だ。「車輪の再発明」的な話だ。ぼくは使うこともあるが、つくることも多い。 2017 の目標 (2016-12-31) を見ても↓のようなものがあるくらいだ。
- 自分の使うものはできるだけ自分でつくる。
あえて、つくることが多い。言い訳的だが、いくつかの理由を挙げておく。
釘をさすように「独自技術症候群 (Not Invented Here (NIH) Syndrome) : 他所で開発された技術を嫌い、すべての技術を自前で用意しようとする考え方」などが何度も書かれる。
シェルスクリプトで既存のものを組み合わせて使えという話。梃子の続きでもある。小さいものがたくさんある前提なのだから、組み合わせる手段が大切なのは分かる。ただ、実際に使っているけれど、これで良いのかはずっと疑問だ。移植性の観点から言えば、コマンドの有無やオプションの違いなどから動かないことも多い。また誤った加工で壊れることも多い。簡単なデータ型も扱えない (扱いづらい) 。そういった理由で壊れていても気づかない (気づくようにつくるのも面倒だ) 。どうなんだろう。
過度の対話を避けるのは良い。これは Windows がそうだったんだろう (そこもまた変わってきている) 。すべて GUI だと操作が必要で大変だ。 GUI だからというよりは CUI でも対話があると同じだ。対話よりはオプションを使って、バッチ的に処理できるほうが便利なことは多い。
すべてのプログラムは……主語がでかい。
『エイプリルフールズ』を観た / 小さなたくさんのプロジェクトを更新する
『エイプリルフールズ』を観た。以前も地上波で観た気がするのだけど、書いていないようだ。
こういう、たくさんの無関係そうなものが、最終的にまとめられていくのが好きだ。
『 UNIX という考え方 』を図書館で借りてきた。軽い読み物のつもりだ。
JavaScript / CoffeeScript / TypeScript プロジェクトの負債を気にしている。どれもきちんと動くが、言語・ライブラリ・フレームワーク・ツールなどに違いがある。ぼくはプロジェクト別にそれらが違っていても良いという立場をとってきたし、今後もそのつもりだ。ただ統一されているほうが処理しやすいのは言うまでもない。
どこかで置き換えるのが良いと思っている。たとえば 5 年のような期間で区切って置き換える、とか。しかし、置き換えには時間が、つまり費用がかかる。見合うものがなければ置き換えづらい。どうしても見合うものを見つけにくい。ただ置き換えずに延々続けるとすこしずつ歪みが出くると思っている。微妙な仕様（ここで言う仕様には既存の実装の都合のような、しがらみを含む）を把握できる人が限られてきたりする。どこかで置き換えが、見直しが必要だと思う。
置き換えを受け入れてもらうために、大きいものを小さいものに分割して細かい単位で置き換えていくのはひとつだ。分割したものの統合もときには必要になりそうだし、オーバーヘッドもあるように思うけれど、すこしずつできるもののほうが受け入れやすいだろう。
一方で小さいものにすると、いろいろ試したくなる。その結果が冒頭の負債に繋がっていたりもする。既にある程度は小さいものが多いので、機会を見て、置き換えを提案していきたいところだ。
小さなたくさんのプロジェクトがあり、それぞれがいろいろなものに挑戦している。きちんと動いている場合の置き換えの提案はなかなか難しい。人が増えるタイミングなどを機に仕様の共有を兼ねて、置き換えていく。そんな感じだろうか……。
もやもや。
bouzuya/rally-cli-hs スタンプラリーの詳細の取得 / ベヨネッタ 8 章
bouzuya/rally-cli-hs でスタンプラリーの詳細項目を取得できるようにした。 Data.Aeson の class FromJSON を適当に組み合わせるとそれっぽく parse してくれるのな。 JSON はよく使うし、いろいろ試しておいたほうがいいんだろうけど、必要とされたときにそれだけを試している。必要となるまで遅延させている。
なんだか体がだるいのだけど、ベヨネッタを 1 章だけ進める。高速道路を走る。長い。テンポが悪い。操作に意味があるのかよく分からない。
bouzuya/rally-cli-hs Data.* への抽出 / ベヨネッタ 6, 7 章
bouzuya/rally-cli-hs で Data.* を切り出す。考えずに手を動かす感じの。
ベヨネッタを 2 章進めた。ゲームで何かを守らされたりするの嫌い。自分だけで精一杯。次は 8 章。あまり進まない。相変わらずガチャっていて、自分でも下手だなあと思う。
定期の散髪。念入りに。
『いかにして問題をとくか』を読んだ
- Polya 『いかにして問題をとくか』を読んだ。数学ガールの「参考文献と読書案内」から選び、図書館で借りた。
題のとおりだけど、どうやって問題を解くかが書いてある。これは個別の問題における具体的な方法の話ではなく、一般的に問題へ取り組むときの方法というメタな話だ。たとえば「未知のものは何か」とか「与えられているものは何か」などだ。
ここで言う問題は数学に限らないとしているものの、例題がそうなっているせいもあって数学へ寄っているように感じた。
正直なところ、読みづらい。何がと言われると難しいのだけど、重要な要素が埋もれていたり、微妙に表現が安定していなかったりする感じとか……。数学ガールでは「例示は理解の試金石」などの決まったフレーズで括弧をつけて、繰り返していたりする。もしかすると訳のせいかもしれない。
以前プレゼントとしてあげたものをプレゼントとしてもらう経験をした。
夕食後にチョコレートっぽいケーキ (名前が分からない) を食べた。中央のしっとりした部分がおいしい。
