読者です 読者をやめる 読者になる 読者になる

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:オブジェクト指向で実装するには言語機能が貧弱すぎるため

感覚分解能と雑に言ったがたぶんニューロンの扱える次元の数が限界値。しかし、下記のように情報を圧縮している。

学習は、人間でも機械でもそんなに変わらなくて、正解と不正解をひたすら突っ込んで内部の状態を作っている。

 

究極的には、人間社会で後天的に学べる概念はネットワーク上の状態として蓄積することは可能なはずである。ネットワーク上の状態とは、まさしくニューラルネットワークの内部状態のことで、あれは情報を入れたら次元を圧縮して出してくるフィルタのようなものとも言えるのではないか。

人間が社会的に学習する概念はDNNで学習可能だとすると、感情はどうなのかという疑問が残る。私の偏見では感情は遺伝子レベルのプリインストールな状態で、他の種や生存上の競合に対抗するためには必須の仕組みだったのだろうと飼っている🐭たちを見て思う。

となると、上記の究極を達成して強い人工知能ができたとしたら、感情とか備えてない可能性はある。強い人工知能さんに人権を与えるかどうかがSF的なおもしろポイントで、我々は感情を持っている動くものに人権を認めているのか、それとも人間レベルの知能を持った種に人権を認めているのかという話になってくる。私の意見としては前者が優勢で、実際一部の人の間ではイルカやペットに人権らしきものが生じている。

なので、感情させ実装しなければ強い人工知能さんの人権問題は杞憂かもしれない。もちろん、強(略)さんのふるまいを見て勝手に人権を付与する人はたくさん出てくると思うので、対人インターフェイスの設計も問題になってくる。

 Twitterでまとまった妄想を書くのはたいへん。

 

余談だが、ニューラルネットワークの出力結果は最初に述べたタグづけに近いものになっていて

gyazo.com

Using deep learning to listen for whales — Daniel Nouri's Blog

ご覧の通りである。

弛緩して捗らないときは服を着替えるとよかった

休日には趣味で作ってるアプリの開発が捗らないという悩みがあった。

今朝、いろいろ考えて、外に出るときと同じ服に着替えてみるというアクションをとってみたところ、すぐに適度な緊張状態に移行して開発が捗った。

たぶん休日は一日中ゆるい服装でひきこもってるのがまずかったのだろう。

てきとうに理屈をつけてみると、「服は身体の一部なので、服を変えると身体と不可分な意識もかわってくる」「ズボンで足を締め付けることで物理的な緊張状態が得られる、血行がよくなる」などが思いつく。

逆に、作業をする必要がなく、精神などを回復させたいときはゆるい服装に着替えるとよさそう。平日の帰宅後などは家にいても仕事の緊張が続いてしまうこともあるので、弛緩する施策も大事にしていきたい。

 

さらに、他人の視線があることによっても緊張状態が得られることが経験的にわかっており、例えば職場、カフェ、コワーキングスペース、リモートワークの常時接続がそれにあたりそう。

リモートワークの常時接続は強制的に家を緊張状態にするアプローチで、即効性はあるのだけど、自宅という弛緩すべき場が職場と同等の緊張状態にされてしまうのは、それはそれでストレスがたまりそうだ。

Immutable.RecordとFlow問題はImmutable v4でなおってそう?

izumin.hateblo.jp

 

Flowに入門して今まで作ってきたReduxのモデルに型をあてようとしてみた。モデルは一部界隈でおなじみの、Immutable.Recordを継承したやつなのだけど、上記の記事のようにImmutable.Recordの型定義がよろしくない問題がある。

なんでそんな酷い型定義が存在するのかと思ってmasterブランチを見にいったらまともっぽい型定義で???と思ったら、以下のcommitで改善されてた。

github.com

よかったですね。v4で入りそう。

 

余談

Immutable v4でRecordがkeydCollectionを継承しなくなってる。

github.com

つまりMap-likeなオブジェクトではなくなった。

It also refactors the internals to no longer rely on a Map, but instead a fixed size List which should result in dramatically faster performance.

とのこと。すごくよかったですね。

Map的なオブジェクトであることを前提にしたコードは死にますが、私はOOP的な場としてRecordを使っているのでImmutable v4で受けられる恩恵は大きそう。

たしかにDSLでサーバ構成は書けるのだけど、書いててあんまり楽しくないというモチベーション。必要以上に構成管理のコードを綺麗にしても意味はないのだけど、サーバアプリばかり書いている人にとっては、コマンドをメソッド呼び出しとして記述するほうが自然に読めると思う。まともなシステム構成ならプロセスの責務は分かれているし、コマンド体系もおおよそ似たようなものだから、各プロセスをオブジェクトと見立てるのに無理はないのではないか。

と、ここまで書いたところでTLのインフラエンジニアより「Chef / itamae, puppetの哲学は、操作手順を記録することが目的ではなく、最終的なサーバの状態をコードに落としているだけだよ」というツッコミが入り、

という理解をして得心を得た。おわり。

必要なのは手続きではなく状態というのは正しいので、書きやすさの文句を言うならDSLの文法だとか実行環境、ツールの複雑さあたりを対象にするのが筋かもしれない。

 

人間の曖昧さによってユーザ入力は何が起こるかわからないので、特にテキスト入力が多ければ多いほどOptionalを扱える言語が相性よさそう。逆に、曖昧な入力が少なければスクリプト言語でえいやっとやってしまってもよいと思う。

自由な入力はnullとの戦いがつきものなので、武器は多いほうがよさそう。

 

ホワイトボードのシートを机に置くと便利

f:id:non_117:20170412214915j:plain

オフィスでやり始めたのだけど、タスクの備忘録とか考えごとの一時避難は机のうえに広げたホワイトボードで管理するようになった。あまりに自分の性格に合ってたので家でも同じことをはじめた。

コード書く前に設計するのにも便利だし、仕事の割り込みをとりあえず書いておいて放置してもよい。また、他人に難しい概念だとか設計の方針を説明するのにも重宝している。雑にタスクを羅列しておけばまわりの人が見て何の業務をして何を積んでいるかもわかってもらえるかもしれない。

普通のホワイトボードは移動式だったり壁に貼ってあったりするものだけど、壁に向かって文字や図形を書くのは結構たいへんで腕が疲れる。訓練を積んでいないと綺麗に文字を書くこともできないと思う。

 

最初はA4サイズのホワイトボードノートを使っていたのだけど、全然紙面が足りない問題があった。そこで、思い切って0.5平方メートルくらい机のスペースを開けてホワイトボードに専有させてみたところ、楽園が訪れたのが数週間前。今では朝にやることを書き出して、キーボードの横のスペースで設計しながらコードを書く生活になっている。

家用に購入したのは、

この商品で、マーカーはPILOTのボードマスターS極細を使っている。ペンは細ければ細いほどよい。

このホワイトボードシートの消しやすさは良好で、ちょっとペラいのが気になるくらい。埃が積もって消しにくくなっても各ご家庭にある無水エタノールを使えば何も問題はないと思う。

 

想定される問題点

机が狭くなる

シートの上に普通に物を置いています。

それでも狭ければ諦めるか整理整頓する気合を発揮してください。空間は縦方向に有効活用できます。

飛沫で服とか床が汚れる

ちゃんと(とは?)消せば消しかすをクリーナーに集めてゴミ箱にぽいできている。マメさはいるかもしれない。

高性能なホワイトボードクリーナーで解決する手もある。

 

以上です。ホワイトボードは書きやすくて消しやすくて最高。