soy-curd's blog

へぼプログラマーです [https://twitter.com/soycurd1]

serial experiments lain見た

20週年らしいので、serial experiments lain見た。演出が独特なので、1話見て無理っぽかったら旧キノアニメを見て体を慣らしてから再挑戦したほうが良い。ストーリーを理解させる気が制作陣になく、最後まで思わせぶりストーリーが延々と続くので、オチとかが欲しい人も見れないと思う。ただそれ以外の要素はかなり面白い。

というわけで、サイバーSF衒学的鬱百合アニメを見たい方にお勧めの作品です。

高野秀行『恋するソマリア』読んだ

最近ワールドカップの日本vsセネガル戦について、「どちらの国も納豆を食すから納豆国対決」みたいな謎の切り口で語っていた高野秀行の、『恋するソマリア』を読んだ。 高野秀行はノンフィクション作家で、最近良く読んでいる。文章が軽快なので、頭使わずに読めるので良い。『恋するソマリア』は、つい最近文庫落ちしたみたいなので、 入手して読んでみた。

内容は、内戦状態の国ソマリアで、現地の家庭で料理を習ったり、部族の長みたいなやつと一緒にアフリカ連合軍の武装車両に乗って戦闘地域に行ったりするかんじで、異常に面白い。

『アヘン王国潜入記』でも、アヘン栽培地域でアヘン農家に混ざりながらヤク中になって終わるという異常なオチで、出版可能なギリギリをついてる印象だったけれど、この本もオチが秀逸なのでやばい。 宮内悠介の紛争物とか、西島大介ディエンビエンフーとか、そういう作品群の文脈で語られても良さそうなぐらい紛争地域であるソマリアに肉薄しているのだけれど、文章をほぼ全部ギャグで昇華させているところが、高野秀行しか書けない感を出している。とりあえず、紛争状態の緊迫感と極度の便秘に陥った肛門のギリギリ感をオーバーラップさせる描写力は、完全に神がかっていて、とても良かった。今後も体調を気遣いながら元気に本を出していって欲しい。

恋するソマリア (集英社文庫)

恋するソマリア (集英社文庫)

アヘン王国潜入記 (集英社文庫)

アヘン王国潜入記 (集英社文庫)

英語に慣れるために英語記事のタイトルだけ訳し始めた

英語に慣れるために英語記事のタイトルだけ訳し始めた。訳した、といっても自分は英語が苦手なので、 完訳ではなくて意味がわからない場合はわかる部分だけメモ書きを残している。

記事本文を読んでいるかというと正直あまり読んでいなくて、見出しの単語だけ追っているかんじに近い。 まあそれでもなにも英語に触れないよりはマシだろうという判断で、すごい暇な時だったり、これは読んだほうが良さそうってかんじのやつだけざっくり読む方針でやっている。

ソースは基本Mediumのおすすめ記事みたいなのから拾っているだけなので、もしダメ記事だったとしたらMediumのおすすめ機能が悪い、ぐらいの気持ちで淡々とリンクをtwitterに貼っている。

いずれは記事本文もちゃんと読んで噛み砕けるようになりたいが、あまり最初からハードルを上げると面倒くさくなってしまいそうだったので、しばらくはこんなかんじでやっていく予定。

(まだ二週間ぐらいしか継続していないが、こうして書いておかないとサボりそうだったので改めて書いてみた。)

バーチャル賽銭箱になって時代の最先端を目指す

f:id:soy-curd:20180613004233p:plain

youtube投げ銭機能がすごくて、実際に月ノ美兎とかおばあちゃんyoutuberとかの生配信とかを見てるとどんどんユーザーから金が投げ込まれていく。100円単位のものばかりかと思いきや1000円単位でぶちこんでいる人もいて、これは明らかに経済の流れの革命であり、絶対に儲かるやつで、この流れに乗るしかないといった思いが高まった。それで週末、家のPCにfacerigを入れて、

配信できる環境を整えるまでやったところで、絵が書けないとvtuberになることができないことに気づき、vtuberになることは断念した。(↑の犬はfacerigのサンプルキャラクター。)

他の手段はないものかと調べてみると、投げ銭サービス的なものは世の中にかなり出てきているようで、pixivの出しているfanboxもその一つだ。fanboxは絵師に投げ銭できるやつで、投げ銭するとそれまで非公開だった画像が見れるようになったりする。

しかしその対価である画像も、つきつめれば物理的実態のないデジタル情報であり、fanboxで投げ銭をしたとしても実態としてユーザー←→クリエイター間で移動するのは投げ銭された金銭の数字だけである(その数字も実態なのかという話もあるが)。つまり、投げ銭だけ可能な状態のfanboxがあったとして、それは他の画像が見れるfanboxのページと物理的には等価なのではないか?

そこで作ったのが先にリンクを貼ったバーチャル賽銭箱だ。このfanboxから、pixivのアカウントを持っている人ならだれでも、お賽銭を投げ入れることができる。自分は絵師でもなんでもないので、投げ銭したからといって絵が見れたりなにかできたりするわけでもなんでもない。これは経済の&>/dev/null/だ。金は天下の回りものというが、この賽銭箱に金を投げ入れてもそれが再び社会を還流する保証は一切なく、ただ純粋にお賽銭を投げ入れることができるのがこのバーチャル賽銭箱だ。

またこのバーチャル賽銭箱にはささいなギミックとしてバーチャルおみくじ機能も設けた。これは引く前からすでに運不運がわかっているという画期的なおみくじだ。凶がひきたければ凶の分賽銭を投げれば良いし、大吉をひきたければ大吉分賽銭を投げれば良い。非常に簡明であり、現代的だ。現実の寺社仏閣もぜひこのシステムを流用してほしい。

なお、このバーチャル賽銭箱にもメリットがないわけではなくて、お賽銭を入れる練習になる、大晦日で神社が混んでいても気軽にお賽銭を入れることができる、お金を捨てる場所に困っていてもここなら気兼ねなく捨てられる、などがある。日頃からお賽銭に困っている方はぜひご活用ください。

制御の反転と DI の関係を完全に理解した

自分は会社で利用している web フレームワークや Angular で DI を日頃から使っているのだけれど、なんかモックとかぶちこめて便利だな、ぐらいの理解で、 制御の反転っていう概念がよくわからなかったし、それと DI がどのようにな関係にあるかについては全然考えていなかった。なので、最近いろいろ調べてわかったことを書いてみる。

まず、制御の反転なのだけれど、wikipediaに概念がまとめられている。しかしDI を念頭にこの文章を読んでも、この説明だとよくわからないと思う。

これはなぜかというと、この wiki に載っている例が、Dependency Injection とは直接関係ないからだ。実装技法 の項目になって、ようやく依存性の注入の話が出てくる。この時点で、依存性の注入制御の反転を行うための一つの手段でしかないことがわかる。

それではいったい DI における制御の反転は何の制御を反転しているのか?ということだけど、これは、クラスの管理(制御)の責務を反転している。

この記事からその責務を抜粋すると、

  • 依存関係の置換または更新を行う(a)
  • 依存関係の有効期間の特定(b)

である。DI においては、クラスの管理(制御)の責務を担うのは、利用する側のオブジェクトではなく、フレームワークだ。

これを Angular のユースケースで考えると、(a)は例えばユニットテストのためにモックの注入を行う場合で、 (b)はフレームワーク側の機能としてProviderSingleton serviceを提供している点だろう。

以上を意識してから読むと面白いのが、この記事この記事 だ。

前者では必要な機能を持った関数を引数として渡したり、部分適用を行うことで依存性の注入を実現していて、後者では、 React は props の機能で DI 相当の機能が実現できるから、DI なんて知る必要はない、と言っている。

つまり、OOP の文脈で DI を実現するためには DI コンテナのようなフレームワークが必要だが、FP においては関数が first class であることで、言語機能として制御の反転を担保している、と言えるのかもしれない。(React は FP 側)

google の Peter Norvig のスライドで、「動的言語でのデザインパターン」というものがあって、この中で GoFデザインパターンのうち 16 個は動的言語では不可視化されるかシンプルになると言っている。確かに Python なんかではイテレータは言語に組み込まれているし、頻出するパターンはプログラマの手を煩わせないように言語設計者が上手く取り込んでくれているのだろう。

もし FP が今後もっと台頭すれば、DI の概念もいずれは、すでに言語にビルトインされたものとして特におおげさに言及されることもなくなるのかもしれないと思った。

Hyperapp × TypeScript × herokuで簡単なアプリケーションを作成した

Hyperapp × TypeScript × herokuで簡単なアプリケーションを作成した。

obenkyou.herokuapp.com

tour of goっぽいかんじで、JavaScriptをサイト上で実行することができる。

処理の流れとしては、右のペインに入力 -> inputを拾って随時stateを更新-> 実行ボタン押下次にinputの内容をevalするactionを実行-> actionの結果を右下に表示というようになっている。

この部分についてはHyperappのstate managerとviewが程よく密結合になっていて、書きやすかった。

コンポーネントの定義だけ抜粋すると下のようなかんじ。ここだけ見るとほぼReactと変わんないんだろうなという気がする。

const JsCode: Component<Props> = ({
  title,
  label,
  description,
  code,
  result,
  error,
  onChange,
  onSubmit
}) => (
  <div class="container">
    <div class="columns">
      <div class="column col-6">
        <h2 class={styles.title}>{title}</h2>
        {descriptionFormatter(description)}
      </div>
      <div class="column col-6">
        <div class="columns">
          <div class="column col-12">
            <label class="form-label" for="textare">
              {label}.js
            </label>
            <textarea
              id="textarea"
              class={styles.codeForm}
              value={code}
              oninput={(event: any) => onChange(event.target.value)}
            />
          </div>
          <div class="column col-12">
            <button class={'btn ' + styles.run} onclick={() => onSubmit(code)}>
              JavaScriptを実行
            </button>
          </div>
          <div class="column col-12">
            <p>
              結果: <span class={styles.result}>{result}</span>
            </p>
          </div>
        </div>
      </div>
    </div>
  </div>
)

hyperapp/routerも試しに使ってみたのだが、ルーティング後に別のactionを発行した時、全体のstateが更新されるのでルーティング処理のルートに再度入ってしまい、変更差分の制御を入れないと無限ループになるのが難点だった(書き方の問題かもしれない)。

上の件以外は特にハマった部分は無く、Angularと比べると意味不明なエラーに遭遇する率が低い印象だった。

それに、bundle.jsのサイズが12.3kbという大きさで収まっているのは、Hyperappならでは利点だと思う。1kbとか公式が言っているだけあって、やはりめちゃくちゃ小さい。

TypeScriptとの相性については、まだRouterが型定義が公開されてないとかあって微妙な部分もあるけど、PRは出ているようなので時間の問題っぽい。

自分は業務ではメインでAngularを使っているのだけれど、ロード時の重さや開発時の重さで中々大変な部分があり、結構辛い。でも今回Hyperappぐらい小さいライブラリでもこの位のものは作れちゃうのがわかったので、実はAngularなんて要らないんじゃないかというかんじもしてきた。

(Hyperappと直接は関係ないが、jsxで条件によってタグ・クラスの出し分け〜みたいなのは、参考演算子がjsxの中に混ざってかなり読みにくいので、AngularのngIfほうが良いかも。ということは可読性&バンドルサイズの小ささで結局vueが最強なのか。。。)

入門 React ―コンポーネントベースのWebフロントエンド開発

入門 React ―コンポーネントベースのWebフロントエンド開発

Angularアプリケーションプログラミング

Angularアプリケーションプログラミング

されたくもないのにメンタリングされることに対する気持ち悪さ

先日、最近流行りの『エンジニアリング組織論への招待』を読んで、その中にメンタリングについての章があった。それによるとメンタリングとは、

対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法です。

と書かれている。自分はこの文章を読んで、まず、「きも、。。。これ洗脳じゃん。。。」と普通に思ってしまった。

こんなふうに思った理由はたぶん簡単で、自分がメンタリングする側の立場ではなく、メンタリングされる立場で読んでいるからだ。つまりメンタリングされる側からすると、よくわからないけど自分の精神の状態を把握され、歪みを補正され、成長させられることになる。こんなに恐ろしいことはない気がする。

なお、この本ではメンタリングの手法として「傾聴」「可視化」「リフレーミング」というものが紹介されるが、これはNLPというジャンルの言葉っぽい。これは神経言語プログラミングの頭文字をとったもので、プログラミングとは全く関係がない、心理学畑の用語のようだ(もちろん、自然言語処理とも関係がない)。この言葉のwikipediahttps://ja.wikipedia.org/wiki/%E7%A5%9E%E7%B5%8C%E8%A8%80%E8%AA%9E%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)を見てみると、疑似科学というワードが出てきて、ああ、やばいな、という気持ちにさらになってくる。

たぶんこの気持ち悪さは、メンタリングに対して知識がないせいだと思う。Fear of the Unknownというやつだ。おそらく本当はメンタリングの技術は正当な科学的背景があって、それを用いることの正当性があるのだけれど、それが上のような疑似科学的な文脈で用いられることがあって、それが自分には知識が無くて弁別できず、一緒にまとめて気持ち悪さを感じさせてしまうのだ。

で、気持ち悪いなら気持ち悪いなりにメリットがないと流行らないはずなので、たぶんメンタリングの手法自体は正しいのだろう。雰囲気的に、メンターがまともならメンタリングもまともになる気がする。『エンジニアリング組織論への招待』では、メンターが導く方向性については正しい前提で話が進んでいるように読めるけれど、これはこの本がフォーカスしているのが「ソフトウェア開発」だからで、ゴールが明確で、「成長」させる方向についてもメンターとメンティーの間で一致できるはずなので、あまり実利的な問題はなさそうだ。これでこの本に対する憂いは無くなった。どんどんメンタリングされていきたい!ジョハリの窓を開示しよう!!!

蛇足として、企業で「メンタリング」という言葉が使われる場合、それは離職率を下げる方法の一つとして使われることがあるようだ(https://college.e-jinzai.co.jp/useful/manager/function-mentoring-that-prevent-new-member-from-retiring/)。なんらかの点で会社と社員のミスマッチがあると離職が発生するわけで、「歪んだ認知を補正」することによってミスマッチが無くなれば、離職率も低くなるだろう、ということだと思う。そんなの補正する前に採用時点で判断しろよ、という気もするが、なかなか難しい話なのだろう(カルチャーフィットを数値可するサービスも出てきているみたいだ https://www.wantedly.com/companies/meryeself/post_articles/81208)。素直な人材が欲しい、というベンチャー界隈の採用方面の気持ちの高まりも、この文脈だと理解しやすい。

以上のようにメンタリングの世間的な流行りを感じるので、学んでおくと生きていくうちの要所要所で効いてきそうなかんじがする。そういう意味で、『エンジニアリング組織論への招待』はメンタリングを学ぶための良い本なので、プログラマーなら一度読んで見ると良いと思う。

なお、こんなひねくれた私を導いてくれる人がいたらぜひ連絡をください(絶賛メンター募集中です)。

マンガでやさしくわかるNLP

マンガでやさしくわかるNLP