しゅみは人間の分析です

いらんことばかり考えます

ホットクック一汁一菜仮説

www.huffingtonpost.jp

katsumakazuyo.hatenablog.com

味噌汁に栄養バランスが最適になるよう、なんでも入れて調理はホットクックに任せる。

味噌汁に入れる具材はまとめて切っておいて冷凍しておくと楽に仕込めそう。

 

個人的にはインドカレーホットクック研究

tsukurioki.hatenablog.com

にも期待している。カレーも味噌汁みたいなものなので、具材を冷凍しておいて、その日の気分で香辛料と味噌を使い分けるのが良いかもしれない。

ただし、ポットにお茶を入れておく運用の知見から、「香りがだいじな食材は作ってすぐ食べるのが一番美味しい(香りが飛んでしまう)」ことがわかっているので、何かしらの工夫が必要そうである。

複利記念日

習慣が複利として効くやつ何度言われても*1実感として理解できていなかったんですが、このたびめでたく実感から言語化することに成功しました。*2今日は複利記念日です。

 

  • 姿勢はほんとうに常によくしておく
  • 素振りは可能な限り毎日
  • お風呂で本を読む
  • 睡眠の質を高める
  • 栄養バランス

*1:1.01を365乗するやつ

*2:自分で気づくまでわからないの本当に困るがとにかくめでたい

もしプログラマが引退してプログラミング教室を開いたら

もしプログラマが引退してプログラミングの個別指導教室を開いたら

転職とかではないです。思考実験に近いもの。引退は必須要件ではない。妻が個人がやっているアートスクールに通っているのを観て、「プログラミング教室」のようなものを今後運営する人は出てくるだろうなと思ったのが背景。*1
なにやらプログラミングが初等教育に入るらしいし、大人にも需要はあるだろう。専門学校があるではないかという意見もあるが、個別指導が暗黙知の伝達において効率がよいのはペアプログラミングをやったことがある人ならわかるはずだ。

生徒のさまざまな要望

プログラミングといっても実現できることは無限に存在する。プログラミングを手段としてゲームを作れることは小学生の時点で理解できるだろうし、果ては芸術的な創作活動もプログラミングを手段とすることができる。
問題は2つある。

  • 初等教育の筋トレ的カリキュラムを楽しめる人は少ない
  • 高等教育の段階だと先生に教えられないことが多すぎる

筋トレ段階のつまらなさ

もちろんカリキュラムに沿った筋トレをたのしめる人もいるにはいる。プログラミング自体が好きな人種だが、たぶんこのひとたちは希少種である。
多くはプログラミングを手段として自己実現や労働手段を得るのが目的だろう。このひとたちにとっては、「数あてゲーム」や「FizzBuzz」なんて面白くないことは容易に想像ができる。
ある程度熟達して経験を積んだプログラマなら、「アルゴリズムとデータ構造」がどれだけ大事かわかるものだが、基礎知識の重要性を初学者段階から理解できるのは一部の運がよい人たちだけである。
結局、初学者は

  • カリキュラムに沿ったコース
  • 野放図に好きなことをやり、サポートだけ先生に求めるコース

を選ぶことになる。当然後者のコストが前者に対して高いので、「先生」になる人は後者を認めないことも可能である。
ピアノ教室に通っていたころ先生に言われたことがあるのだが、大人は後者の実践コースを選びたがって基礎を身につけずに、形だけでやりたがる人が多かったらしい。

実践に近い教育のむずかしさ

例えば生徒がゲームを作りたいとする。サーバ開発者がバックグラウンドの先生はゲーム作りの疑問に答えられるだろうか?
アートスクールでは、「xxは私(先生)はもっていないので何も言えないが、ooが**な点はよいと思う」のように素直に知らないことは知らないと伝えるそうだ。
プログラミングでは、さまざまなフレームワークや言語、OSなどの目的によって全く異なるといってよい環境の違いがある。たぶん生徒が、謎のフレームワークでハマっていても一緒にコードを追ってドキュメントを読むことしかできないだろう。*2
基礎になるとすれば、

くらいだろうか。アートスクールと同様に共通に使える暗黙知だけ共有して、ちゃんと褒めていくくらいしかとれる手段はないだろう。
英語は正直なところどうしようもなくて、読めない人に英語を教え始めるのはなかなか重い仕事になると思う……。

ゲーム制作専門の教室

なにかの領域を専門とする高等教育の教室があればよい問題でもある。適切に住み分けることは、教室同士の生き残りにもつながるだろう。

集団開発の機会

プログラミングを手段として一人で実現できるシステムの大きさにはやはり限界がある。当然、組織的な開発を行ったほうが大きなものを作れるし、企業同士の競争のなかでプログラマという職が存在している。そのため、手に職を求める人にとっては集団開発の経験はあればあるほど有利である。
しかし、個別指導ベースの教室で「集団制作のチームを組んでください」と言えるだろうか……。あるいは、「先生といっしょにシステムを作りましょう」を低コストで実現できるだろうか……。
この問題も、ひとつの教室で賄わずに外部化し、斡旋するネットワークを持っておくくらいが妥当な解ではないだろうか。

個別指導に向いているのは

  • 素直に褒めるのがうまい
  • 言語化がうまい
  • 専門外の知識を薄くは持っている

素直に褒めるスキルの時点で私を含めた大半のプログラマが向いてなさそう。専門家であり感情労働的でもあるので、向いてない人はやらないのがよいと思う。しかし、向いている人であれば引退あるいは副業とするのもおもしろそうな業である。

まとめ

  • プログラミング個別指導ありでは
  • カリキュラム的にやりたいが大人にはつまらない問題がある
  • 実践教育は責務を分けたほうがよい
  • 集団開発も責務を分ける
  • 向いている人だけやればよいのでは

f:id:non_117:20180322233243p:plain *3

*1:たぶんすでにあるとは思う

*2:そこで問題を解決していくさまが暗黙知ではある

*3:妻が描きました

家事の負担について

公平さなんてものはないので、公平感を求める。

快適さや生存に関わる家事とそうでないスポット的な家事を分けて考える。ライフラインとなる家事は単一障害点がないほうがよい。つまり、最低2人はライフラインとなる家事を遂行する能力がないといけない。しかし、誰がやってもよい状況ならば得意な人がやったほうがよい。自分にとって得意で他の人にとって得意でないことは主観的な労力の割に高い家事ポイントを得られるので、基本戦略としては相対的に得意なものから割り当てるとよい。

そうして、生活に関わる労働雑務を全体として評価して公平感があればよい。

ただし、潜在的な不満があるのが人間の難しさで、不満があっても言語化されるレベルまで煮詰まってないこともある。これをどうするかは一般的な解決策はなくて、当事者たちにとって都合のよいコミュニケーション方法を模索するしかないのではないか。

ただし、誰にとっても労働感のある家事があるならば積極的に自動化したほうがよい。もし、皿洗いが苦ではない人で構成されているならば、無理に食洗機を購入して生活スペースを圧迫する必要もない。たぶん、都市生活者にとって最も価値*1が高いのは居住空間である。

また、家事の主観的な負担もその人らの賃金労働が生活にしめる割合で変わってくるため、以上の議論は家にいる時間が比較的少ない人の視点によるものである。

 

全然関係ないのですが、弊家庭ではここ2週間ほどライフライン家事*2を休日に持ち込まない施策を試しています。というのも、賃金労働に時間を吸われている人間にとって2日間の休暇はなにものにも代えがたいもので、休日に「あの家事をしなければならない」という強迫観念に追われるのはかなり大きなストレスになる。

また、趣味のコーディングやお絵かきといったクリエイティブ的とされる活動はある程度長い時間をストレスなく確保できるほうが生産性がよい*3。それならば、平日の定時後の時間でライフライン家事をこなしておいて、休日はライフライン家事を一切やらなくてもよい状況にしたほうが、休日を全部満喫することが可能になる。 

今のところライフライン家事を平日にすべてやっておくのも無理なく実行できており、休日は後腐れなく好きなことだけをやれるようになっている。

f:id:non_117:20180316230706p:plain*4

*1:価値とはなにか?

*2:今生まれた造語です

*3:主観です

*4:挿絵です

🍛PDCA

今日はなぜか美味しくできて、何が原因だったのかよくわからない。

てきとうに立てたインスタンスsshして、なんとなくパッケージを入れたり設定ファイルをいじったら何故かアプリやミドルウェアが上手く動くようになったみたいな。

 

やったこと

  • 冷凍玉ねぎの解凍
  • 余り物の白ねぎも刻んで入れた
  • オリーブオイル多め
  • 玉ねぎ焦がす寸前
  • 生姜多め
  • 🍅は分量を守る
  • コリアンダーターメリック、チリペッパーは1.2倍くらい

Reactのstateに何を入れるべきか問題

暫定の結論

60fpsの世界を実装したことはないのでその辺は対象外です。
いかにも当たり前っぽい結論になりましたね。また何か思いついたら日記にしていきます。

考えたときの思考をシリアライズしたもの
  • UIの状態とデータの状態に大きくは分けたくなる
    • どちらにもまたがるケースが出てくる
    • リストの順序
    • 決めの問題として、データに寄せてもよい
  • 後から仕様変更で、UIの状態からデータの状態に移動するのがダルいという意見
  • 究極的にはすべてをデータの状態として管理するのは可能ではある
    • Fluxループを回るのがダルい
  • 二つの問題が混ざっているのに、境界がはっきり引けない系の問題
  • UIの状態とはなんなのだろうか?
    • UIとはなんなのだろうか?
      • データを人間にわかりやすく伝える手段
      • データを人間にとってわかりやすく操作する手段
      • データの閲覧・操作が目的
    • データをUIとして表現する
    • データとその表現、特に表現を共有するとはなんなのか?
      • データとデータの依存関係
      • observerパターンでは?
      • Rx川の予感
        • 実際にネイティブアプリ界では流行ってるらしい
    • なんでUIの状態に依存関係が?
      • たぶんデータそのものに依存関係がある
      • 目的はデータの操作で楽をさせてあげるため
      • 依存関係をもとに自動化をしている
    • データに依存関係あるなら、データレイヤで変化を伝えればいいのでは?
      • ほとんどのケースではこれが正しい
      • しかし
        • Fluxループを回るので遅いケースがある
    • 依存関係のないUIの状態
      • ある
      • モーダルが開いてるよ
      • フォーカス当たってるよ
      • コンポーネントの中に隠蔽した状態でよい
    • 結論
      • 原則としてUIの状態はデータの状態から自動的に求められる
      • データを操作するのがUIの目的
      • データの依存関係は原則データレイヤ、つまりドメインモデルの操作で解決されるべき
      • データに紐付かない、中間状態としてのUIの状態はコンポーネントに持ってよい
      • コンポーネントが表現する状態(props)と、コンポーネントが内部に隠蔽する状態(state)がある

Scrapbox上で寝ながら考えたところたいへん捗りました。
見返してみると、最初の方は問題がうまく分割されていないために用語が複数の文脈を背負っていたり、最初と最後で矛盾しているかのように見える文章になっていますが、問題が解決されていく様とはこんなもんなのでいいとしましょう。

*1:軽量なUIを作るのならば、ルートコンポーネントのthis.stateにドメインモデルの状態を保持するのも例外的に許容できる