もしプログラマが引退してプログラミング教室を開いたら
もしプログラマが引退してプログラミングの個別指導教室を開いたら
転職とかではないです。思考実験に近いもの。引退は必須要件ではない。妻が個人がやっているアートスクールに通っているのを観て、「プログラミング教室」のようなものを今後運営する人は出てくるだろうなと思ったのが背景。*1
なにやらプログラミングが初等教育に入るらしいし、大人にも需要はあるだろう。専門学校があるではないかという意見もあるが、個別指導が暗黙知の伝達において効率がよいのはペアプログラミングをやったことがある人ならわかるはずだ。
生徒のさまざまな要望
プログラミングといっても実現できることは無限に存在する。プログラミングを手段としてゲームを作れることは小学生の時点で理解できるだろうし、果ては芸術的な創作活動もプログラミングを手段とすることができる。
問題は2つある。
- 初等教育の筋トレ的カリキュラムを楽しめる人は少ない
- 高等教育の段階だと先生に教えられないことが多すぎる
筋トレ段階のつまらなさ
もちろんカリキュラムに沿った筋トレをたのしめる人もいるにはいる。プログラミング自体が好きな人種だが、たぶんこのひとたちは希少種である。
多くはプログラミングを手段として自己実現や労働手段を得るのが目的だろう。このひとたちにとっては、「数あてゲーム」や「FizzBuzz」なんて面白くないことは容易に想像ができる。
ある程度熟達して経験を積んだプログラマなら、「アルゴリズムとデータ構造」がどれだけ大事かわかるものだが、基礎知識の重要性を初学者段階から理解できるのは一部の運がよい人たちだけである。
結局、初学者は
- カリキュラムに沿ったコース
- 野放図に好きなことをやり、サポートだけ先生に求めるコース
を選ぶことになる。当然後者のコストが前者に対して高いので、「先生」になる人は後者を認めないことも可能である。
ピアノ教室に通っていたころ先生に言われたことがあるのだが、大人は後者の実践コースを選びたがって基礎を身につけずに、形だけでやりたがる人が多かったらしい。
実践に近い教育のむずかしさ
例えば生徒がゲームを作りたいとする。サーバ開発者がバックグラウンドの先生はゲーム作りの疑問に答えられるだろうか?
アートスクールでは、「xxは私(先生)はもっていないので何も言えないが、ooが**な点はよいと思う」のように素直に知らないことは知らないと伝えるそうだ。
プログラミングでは、さまざまなフレームワークや言語、OSなどの目的によって全く異なるといってよい環境の違いがある。たぶん生徒が、謎のフレームワークでハマっていても一緒にコードを追ってドキュメントを読むことしかできないだろう。*2
基礎になるとすれば、
くらいだろうか。アートスクールと同様に共通に使える暗黙知だけ共有して、ちゃんと褒めていくくらいしかとれる手段はないだろう。
英語は正直なところどうしようもなくて、読めない人に英語を教え始めるのはなかなか重い仕事になると思う……。
ゲーム制作専門の教室
なにかの領域を専門とする高等教育の教室があればよい問題でもある。適切に住み分けることは、教室同士の生き残りにもつながるだろう。
集団開発の機会
プログラミングを手段として一人で実現できるシステムの大きさにはやはり限界がある。当然、組織的な開発を行ったほうが大きなものを作れるし、企業同士の競争のなかでプログラマという職が存在している。そのため、手に職を求める人にとっては集団開発の経験はあればあるほど有利である。
しかし、個別指導ベースの教室で「集団制作のチームを組んでください」と言えるだろうか……。あるいは、「先生といっしょにシステムを作りましょう」を低コストで実現できるだろうか……。
この問題も、ひとつの教室で賄わずに外部化し、斡旋するネットワークを持っておくくらいが妥当な解ではないだろうか。
個別指導に向いているのは
- 素直に褒めるのがうまい
- 言語化がうまい
- 専門外の知識を薄くは持っている
素直に褒めるスキルの時点で私を含めた大半のプログラマが向いてなさそう。専門家であり感情労働的でもあるので、向いてない人はやらないのがよいと思う。しかし、向いている人であれば引退あるいは副業とするのもおもしろそうな業である。
まとめ
- プログラミング個別指導ありでは
- カリキュラム的にやりたいが大人にはつまらない問題がある
- 実践教育は責務を分けたほうがよい
- 集団開発も責務を分ける
- 向いている人だけやればよいのでは
家事の負担について
公平さなんてものはないので、公平感を求める。
快適さや生存に関わる家事とそうでないスポット的な家事を分けて考える。ライフラインとなる家事は単一障害点がないほうがよい。つまり、最低2人はライフラインとなる家事を遂行する能力がないといけない。しかし、誰がやってもよい状況ならば得意な人がやったほうがよい。自分にとって得意で他の人にとって得意でないことは主観的な労力の割に高い家事ポイントを得られるので、基本戦略としては相対的に得意なものから割り当てるとよい。
そうして、生活に関わる労働雑務を全体として評価して公平感があればよい。
ただし、潜在的な不満があるのが人間の難しさで、不満があっても言語化されるレベルまで煮詰まってないこともある。これをどうするかは一般的な解決策はなくて、当事者たちにとって都合のよいコミュニケーション方法を模索するしかないのではないか。
ただし、誰にとっても労働感のある家事があるならば積極的に自動化したほうがよい。もし、皿洗いが苦ではない人で構成されているならば、無理に食洗機を購入して生活スペースを圧迫する必要もない。たぶん、都市生活者にとって最も価値*1が高いのは居住空間である。
また、家事の主観的な負担もその人らの賃金労働が生活にしめる割合で変わってくるため、以上の議論は家にいる時間が比較的少ない人の視点によるものである。
全然関係ないのですが、弊家庭ではここ2週間ほどライフライン家事*2を休日に持ち込まない施策を試しています。というのも、賃金労働に時間を吸われている人間にとって2日間の休暇はなにものにも代えがたいもので、休日に「あの家事をしなければならない」という強迫観念に追われるのはかなり大きなストレスになる。
また、趣味のコーディングやお絵かきといったクリエイティブ的とされる活動はある程度長い時間をストレスなく確保できるほうが生産性がよい*3。それならば、平日の定時後の時間でライフライン家事をこなしておいて、休日はライフライン家事を一切やらなくてもよい状況にしたほうが、休日を全部満喫することが可能になる。
今のところライフライン家事を平日にすべてやっておくのも無理なく実行できており、休日は後腐れなく好きなことだけをやれるようになっている。
Reactのstateに何を入れるべきか問題
暫定の結論
- ドメインモデルをコンポーネントとして表現する場合は、Viewの外*1に状態を持ち、propsとして状態を流し込む
- ドメインモデルの表現ではない状態(UIとしての中間状態)はstateとしてコンポーネントの内部に隠蔽して保持する
- UI上の操作で、別のコンポーネントの状態が変わってほしいときは、ドメインモデル同士のインタラクションで解決できないか立ち止まって考えてみる
- 異なるコンポーネントのstate同士を連携させたいときは、それらがドメインモデルとしてくくり出せないか考えてみる
60fpsの世界を実装したことはないのでその辺は対象外です。
いかにも当たり前っぽい結論になりましたね。また何か思いついたら日記にしていきます。
考えたときの思考をシリアライズしたもの
- UIの状態とデータの状態に大きくは分けたくなる
- どちらにもまたがるケースが出てくる
- リストの順序
- 決めの問題として、データに寄せてもよい
- 後から仕様変更で、UIの状態からデータの状態に移動するのがダルいという意見
- 究極的にはすべてをデータの状態として管理するのは可能ではある
- Fluxループを回るのがダルい
- 二つの問題が混ざっているのに、境界がはっきり引けない系の問題
- UIの状態とはなんなのだろうか?
- UIとはなんなのだろうか?
- データを人間にわかりやすく伝える手段
- データを人間にとってわかりやすく操作する手段
- データの閲覧・操作が目的
- データをUIとして表現する
- データとその表現、特に表現を共有するとはなんなのか?
- データとデータの依存関係
- observerパターンでは?
- Rx川の予感
- 実際にネイティブアプリ界では流行ってるらしい
- なんでUIの状態に依存関係が?
- たぶんデータそのものに依存関係がある
- 目的はデータの操作で楽をさせてあげるため
- 依存関係をもとに自動化をしている
- データに依存関係あるなら、データレイヤで変化を伝えればいいのでは?
- ほとんどのケースではこれが正しい
- UIの状態を共有するのはアンチパターン
- しかし
- Fluxループを回るので遅いケースがある
- JavaScriptを使うなネイティブでやれ
- Fluxループを回るので遅いケースがある
- ほとんどのケースではこれが正しい
- 依存関係のないUIの状態
- ある
- モーダルが開いてるよ
- フォーカス当たってるよ
- コンポーネントの中に隠蔽した状態でよい
- 結論
- UIとはなんなのだろうか?
Scrapbox上で寝ながら考えたところたいへん捗りました。
見返してみると、最初の方は問題がうまく分割されていないために用語が複数の文脈を背負っていたり、最初と最後で矛盾しているかのように見える文章になっていますが、問題が解決されていく様とはこんなもんなのでいいとしましょう。
チャンネルのS/N比を最大化する
背景
問題
SNSで流れている情報のS/N比は著しく低い
情報のS/N比
- 自分にとって有用な情報がsignal
- 自分にとってどうでもいい、害のある情報がnoise
noiseの処理に認知リソースを割くと人が怒る
例
- はてなブックマークでタイトルで釣る
- Slackのチャンネルのほとんどが興味のない馴れ合い
SNSにnoiseが多い問題
チャンネルとは
何らかのシステム => 自分
の入力関係
対策
S/N比を最大化するシステムを作る
- 手動でフィルタを管理するのは非効率だし面倒
チャンネル
のフィルタを動的に生成する
アウトプットは量多い方がいい。フィルタは各自がやればいい。この原則わかんない奴はインターネット合わないと思う。