問題について

人によって解決できる問題の複雑さ(大きさ?)には限界があると思っていて、それは忍耐強さとか問題を解決してきた経験に左右されてしまうとも思っている。問題解決の方法そのものは抽象的なメソッドとして言語化できるものではなく、暗黙知に属するが、しかし、知的労働者なら暗黙知のベールを破壊しないでどうするという葛藤もあり……。

そこでレビューというフローが便利で、これは暗黙知暗黙知モナドに包んだまま個別具体的な問題の解決方法を示唆していく教育手法だが、現状これ以上の指導方法が実践されてはいなさそう。*1

私が大学院生の頃の研究は散々なもので、難しい問題を前にすると1秒も考えずに思考停止していたし、当時の私が今の私の分解できる問題に対応できたとはとても思えない。なので、他人の問題解決能力をとやかく言うことはできないのだ。

実社会で解かれる問題に、アトムとしての分割された問題が難しすぎるケースはごく稀で、難しい問題は複雑であるだけだと思っている。*2*3なので、問題を諸問題へ分割するのが問題解決なのだけど、これもまた(これこそが)暗黙知ということでこの話はおしまいです。*4

*1:というか問題解決の手法が一般的に言語化(記号化)されたらあらゆる問題が機械によって解決可能になる

*2:難しい問題を解いたら残りすべてが作業になってしまうあれです

*3:しかし実際には作業でミスをする

*4:おなかがへりました

近況

業務

  • Railsサーバ屋さん かつ フロントエンド屋さんからインフラ屋さんへ
  • 業が何か変わったとかではなく、他のプロジェクトでは異なる役割をやってみようかくらいのあれ
  • chef鈍重で面倒なイメージがあったけど、ちゃんと構造化すれば便利
  • 業務水準で上から下まで作れるようになってよかった

引っ越した

  • 旧居が大通りに面しており自動車の騒音がひどかった
  • 利便性は奥まった場所でも確保できるので、車の多い環境に住むべきではなかった
  • 引っ越し
    • 物を捨てる労力が半分くらい
    • 読まない本を捨てられない問題
    • 壁の穴はティッシュを詰めてもごまかせない

自転車通勤

  • fitbitの安静時心拍数が有意に上がって調子が良い
  • 体脂肪率が単調減少し続けている
  • 可処分時間が50分くらい増えた
  • 京都駅が憎い

水耕栽培

f:id:non_117:20170905223413j:plain

  • 契機はわすれた
  • これは青梗菜
  • 毎日大きくなっていておもしろい
  • 日照が足りない場合は植物用LEDライトを買うとよい

家電買い替え

外食が苦手でコンビニも飽きるので、より自炊をしやすい環境を作っていっている

冷蔵庫

  • 毎日仕事が終わったあとに献立を決めてスーパーへ行くのは非効率
  • 肉や野菜をまとめ買いしてもある程度鮮度を保てる装備が必要

aqua-has.com

  • 選考基準
    • でかすぎない
    • フレッシュルームと野菜室がある

感想

  • 左開きのほうが良かったが、高級品(10万以上)にしかそのようなオプションはなかった
  • 概ね満足している
  • 肉をそこそこ長期保存しても問題ない
  • 用途別の扉に分かれていると、お茶などの取り出しで肉・野菜室の温度が下がりにくいメリットがありそう

オーブンレンジ

panasonic.jp

  • 選考基準
    • オーブンが欲しかった
    • 魚が焼けるとうれしい
    • 温度センサー分解能がミドルレンジモデルの8倍(すごそう)
    • 新製品が出た直後で型落ちモデルが安くなっていた

感想

  • コンビニの食品を温めただけなのに、なぜか以前より美味しい
  • あたためモードで食品の目標温度を1度単位で設定できる
    • いみがわからない
  • パンを焼いてもなぜか美味しい
  • あらゆる料理が作れる
  • 蒸気が出るので蒸し野菜作り放題

焼きそば

f:id:non_117:20170911195941j:plain f:id:non_117:20170911200046j:plain

出力

f:id:non_117:20170911202454j:plain

ふつうに美味しくて謎
最高の商品です

Cooking Hacks

cooking hacksで検索すると何故かIoT文脈の

www.cooking-hacks.com

が出てくるが食べられないRaspberry Piではなく料理のほうのお話。

 

最近我が家ではオレンジやパイナップル、グレープフルーツなどを食べるのが流行っているのだが、温州みかん以外の皮が厚い柑橘類は皮と身を包丁で分離するのが難しく、しかし手を果汁まみれにしてかぶりつきたくない問題があった。

 

www.youtube.com

解はこのようになっていて、たいへんエレガントである。

他にも、

www.youtube.com

www.youtube.com

www.youtube.com

このような有用なcooking hacksと呼ばれる叡智がYoutubeに集まっていることがわかった。

3つ目の櫛のような器具はスライスヘルパーとかオニオンホルダーと日本では呼ばれるもののようだ。

www.youtube.com

総集編的なやつがこれ。

フルーツの剥き方も様々な流派があるようだ。

ReactのViewとはどこか

  • ReactとVue, AngularはViewコンポーネントソースコードの構造に、JavaScriptが主かHTMLが主かという違いがある
    • ファイル単位としてのReact ComponentはViewだが、より詳細にみていくとrender()のなかのreturnのみがView(狭義)ともいえる
      • ReactはView(広義)までロジックが地続きになる
      • MVVMでのViewModel, ControllerがReact Component内のrender()以外と対応するのかもしれない
    • ロジックが地続きになっていると柔軟性は高そう
      • 柔軟性はコントロールが難しくてカオスになりやすい
      • React Componentの中にほとんどすべてのロジックが書かれたソースコードを我々はたくさん見てきた
    • この処理は間違いなくここ!という切り分けが常にできるとは限らず、現実世界に低い負荷で対応できる点で柔軟性は重要
      • ただし過剰な柔軟性ということもある
      • その他フォルダ問題
  • モジャッ
    • 難しくて思考が発散したので今日はここまで
    • やはりReactだけでフロントエンドGUIはいけるのでは
      • Reduxいらない派

Flowtypeの問題点

利用者のほとんどがOCamlを書けないので、OSSとしてのメリットが減ってしまう構造的問題。*1

*1:issueでflowの設計・実装の問題点についてではなく、いかにエラーを回避するかが議論されててかなしくなった

srknr.hatenablog.com

これを読んで気づいたのが以下。

AppStoreの上位が企業によるアプリケーションで占められているように、いくら生産手段が労働者に属しているとはいえ、分業と豊富なリソースでの殴り合いに個人は勝てない。そういう意味では富と人間を集約した労使関係が必要にはなるのだけど、会社組織の構成員はそれぞれ生産手段を独占しているので、資本家が生産手段を有していた時代に比べるとだいぶ労働者が強く、マネジメント層は労働者と仲良く働いていく必要が出てくる。

基本的にみなさんがエンジニアと呼んでいる労働者は、優秀であればあるほど上司や会社の言うことを聞く必要がない権利を有しているので、優秀な労働者を使ってうまくやっていくには快適な労働環境や労働者が共感できる文化が必要なのだろう。

このことにGoogleは相当前から気づいていたようで、組織に跨る文化を何よりも重視していたようだ。

属人化の問題はどうしようもないので、ユビキタス言語とか言い出した人がいるのかもしれない。

DDDを読んでる途中でのネットワークシステム設計雑感

フロントエンドGUIの設計について考えていたら設計沼にはまり背骨となる思想を求めてDDDを読んでいる状況です。
フロントエンドを含めたネットワークシステム全般の設計についての雑感。

  • RDBのテーブルの抽象としてORMで対応するモデルはドメインモデルではない
    • RDBの制約のうえでの最適な構造と、ドメインモデルの構造は必ずしも一致しない
    • 取れる対処はORMを介さず直接クエリを書いてドメインモデルに変換するか、ORMを使ったうえでテーブル抽象のモデルの上にドメインモデルを組み立てるか
  • サーバはAPIに特化してしまえば、サーバ側にドメインモデルは必要ないか?
  • クライアント(ネイティブ含む)の環境でドメインモデルは?
    • GUIは複雑なため絶対に必要
    • ただし、サーバとクライアントの間で情報を共有するのに、何らかのシリアライズフォーマットを経由する必要があり、シリアライズ / デシリアライズの仕組みが必須
    • ここでJSONの辛さが浮かび上がってくる
    • なるほどGoogleがProtocol Bufferを作るわけだ
  • クライアントとサーバでドメインモデルは同じ構造か?
    • 微妙に違うが同じにできるケースも多いと思う
    • 同じにできなくてもコアの要素集合は近く、生えているメソッドが異なりそう
    • ここでIsomorphicの利点がわかってくる
  • JavaScriptでシステムを書きたいか?
    • 絶対に嫌だ*1
    • できればC# が現実的な選択肢になってほしい……(個人の信仰です)
    • > Scala.js <

以上。

*1:オブジェクト指向で実装するには言語機能が貧弱すぎるため