個人事業主になったので真面目にアウトプットしてみるブログ

フリーで顧客の会社に潜り込んでAndroidアプリつくって、とりあえず食っていけるようにアウトプットを増やしていくブログです。

2018年上半期で読んでよかったっと思った本1冊

注意、隅々まで読んでいるわけではないです。

沢山Kindleや紙のほうの書籍でいろいろ買ったきがするんですが、そこまで紹介できる本はないです。 それでもこれはなかなか良かったなーとおもったので。 とりあえず紹介したくてブログにしました。

武器になる哲学


この書籍は、よくある小難しく哲学をする本ではないです。なので変に構えて読む必要がなく、また文章も頭がいい人が、自分の程度を見せたくて書いた本でもなく、とても読みやすい本だと思います。
この本は、実用的な哲学による教訓やその背景などの解釈の方法と、実際の有用な例を示してあり、現代社会にも通じる知識として紹介されていました。
僕はこういうものは、ネットで情報過多になってしまいがちであるからこそ、情報の価値判断をする前提のために基礎教養として現代人が持っているべきなんじゃないかなと思いました。

紹介されている例の中でとても役に立つことがあったのでここでいくつか紹介します。

一つ目。ニーチェの「ルサンチマン」に関する紹介は興味深いものでした。
現代社会でのブランディングのほとんどは「ルサンチマン」という他者に対する「うらやみ」、「やっかみ」のような感情をあおる事で起きる人の不安定な状態を利用して、その不安定な「ルサンチマン」という心の状態を解決させようとすることで、実際の価値よりも高いものを売りつけることをベースに成り立っているというものでした。実際にフェラーリなどの、実際の用途としては別の価値を付加され必要以上のものを買うという心理は、この「ルサンチマン」によるものだといえます。

二つ目に興味深いとおもったのはレオン・フェスティンガーの「認知的不協和」の話。
これには二つの要素があります。まず「認知的不協和」の状態になること。そしてそれを解消するために人がとる方法についてです。まず前者は自分が合理性のないことを行ったとき、他者によって自分の中の合理性をゆがめられてしまったときに、認知的な歪みが発生する、この状態のことです。(何かしら違和感があるときに発生しているように思えますが、実際は僕たちは認知的なギャップをほとんど常に外界からもたらされるので、常に僕たちの中で起きているものだと思います)そして、後者ですが、そういった事象と認知のギャップが起きると、その不安定な状態を解消しようとします。具体例でいうと「あの人と目と目が合うのは僕のことが好きだからだろう」みたいなやつですね。もしくは「たまたまうまくいったことを、自分の能力に紐づけて説明しようとする。」という感じでしょうか。
三つ目が、報酬についての話。
これは最近はとくに課金ガチャなどの話があるので有名な事かもしれませんが、報酬が不確定であればあるほど、動物は狂ったように報酬を得ようとするという話で。ドーパミンが欲求を起こし、報酬を得るとオピオイドによって快楽がもたらされ、ドーパミンの放出を抑制するという話です。(どこが哲学なんだよ!だが実用的だな乙。)

3つ紹介しましたが、このことから僕は、人は外界から発生した事象から不安定になると、その状態を解決し自ら安定化しようとする。ということと、不確定な期待値のある状態にたいして強く心理的な働き(ドーパミンの放出)がおこり報酬を得ようとする。
そしてそれらはきわめて人間が反応的で、不合理な生き物であるということの仮説を立てるのに十分な動機を与えてくれ。さらに人間の行動はある程度プログラム可能であることができるという仮説を生ませる。(やる気と行動という部分に限ってしまえば、人間って難しいように思えて実は単純な生き物なのでは?という気にもさせられ、最近はやりのJob理論なんかよりも全然役に立つ気がします。)

これは武器ですよ。守るための武器にも、攻めるための武器にもなりえそうな知識だと思います。この本はそういった内容で満載なので、下手なマーケティングの理論の本よりも本質的かつ実践的で、人類が歴史的に積み重ねてきた英知の一旦を垣間見ることができるかもしれないです。



哲学からまさか人間が機械的な反応を示す部分があるなんて思ってもみなかったです。
もっとハートがあつくなる系の話かと思っていました。まだ半分も読んでいないので、通勤中にじっくり読み進めようと思います。

僕の業務上のAndroid GUIプログラミング変遷

特に深いことを書く余裕がないんだけど。 それでもいいって、余裕がある人は読んでいってね。

僕はプログラマとして特にAndroidのアプリの開発で一番コードを書いてきた。 ちょっと分解していうなら、Javaな言語仕様な感じのAndroidフレームワーク依存のGUIプログラミングを主にやって来た。 そういう経験下で得られた認知的バイアスがあると思うのでそういう風に受け取ってもらえると嬉しい。

続きを読む

採用に地頭のよさは必要か?

t.co

この記事を見て思ったんだけど、たしかに頭が回らない人よりは、フェルミ推定的な方法論をしらないでも天然で現実的なロジックの積み上げや、抽象度をあげた検索によって有効性のある点をみつけて一気に前に進む感じの人はいい人に映るんだけど。 はたしてそうか?

というのが疑問。

続きを読む

プログラミングについて雑語り

とりあえず失敗しろ。 失敗したら、その失敗がなぜ起きたか考えろ。 その失敗をしないために、どうしたらいいか考えてみろ。 考えたら本当にそれやりたいか考えてみろ。 やってもいいかなって思うくらいの妥協ポイントを見つけろ。 妥協ポイントについてのポイントをまとめて、妥協ポイントをブラッシュアップをしろ。

って冗談。

そこまでやる必要はない。なんとなくアレは失敗だったのかなー?って悩みつつ時間が解決してくれるのを待てばいい。 ポエムとかではなく、これはHow to。

続きを読む

自明なコードを書く

今日は、自明なコード。つまり読みやすいコードについて話をします。
設計で読みやすいコードにすることもできる例としてはDDDがあります。

※先日もちょっとDDDについては触れました。
http://pooh3-mobi.hatenablog.jp/entry/2018/04/20/020654
もっと基本的な部分、たとえばJavaでいうメソッドの中のコードについてはどうでしょうか?
割とおざなりになっているか、リーダブルコードという書籍を基準に考えられている方が多いのではないでしょうかね。
今回は、おそらくそういった部分ではカバーしきれていない部分について、重箱の隅を楊枝でほじくる感じで書いてみます。

続きを読む

RxJavaでリアクティブプログラミング

今回はKotlinで書きます。

RxJavaでリアクティブプログラミングについて軽く触れたいとおもいます。

リアクティブプログラミングとは?

簡単にいうと逐次にフィードバックが返ってくるように処理を書くことで、ユーザに何も反応がない状態をさけるようなGUIプログラミングに主に使われるプログラミングスタイルです。
リアクティブプログラミングをするには特にRxJavaが必要というわけではありません。
ただしRxJavaを利用することでリアクティブプログラミングをする上でいくつかのメリットがあります。

たとえばRxJavaはRxBindingと合わせると、リアクティブプログラミングをやりたいときのコールバック地獄の問題を緩和してくれる。
これは非常にありがたいです。

つぎに合成的な処理や高階関数の利用が可能になるので、多少複雑なことが簡単に書けてしまう。

というメリットがまず代表的なものだと考えます。(非同期性の部分は副次的なものと考えます。)

例えばこんな感じのコードはどうでしょう?

  fun onCreate() {
        val a = editIntTextA.textChanges()
                .map { s -> s.toInt() }
        val b = editIntTextB.textChanges()
                .map { s -> s.toInt() }

        val sum = Observables.combineLatest(a, b, {a_, b_  -> a_ + b_})

        sum.map{ i -> i.string }.subscribe(output.text())
  }

このコードは2つのEditTextに入力された数値を足した数字をTextViewにアウトプットするものです。
どちらかのEditTextの入力され文字列(数値)が一つでも変わるとすぐに計算結果がTextViewに反映されます。
リアクティブプログラミングを実践するコードとしては単純ですが、良い例になります。

このように、二つのイベントを組み合わせ一つのストリームとして処理したり、イベントの発火は契機にして欲しい値に高階関数をつかって置き換えをすることにたけているのがRx系のライブラリの良いところでしょう。

非同期処理用のライブラリとして使うのもよいのですが、既存のAPIがコールバック式になっている場合に、どうやってうまくデータのストリームを副作用のある終端にもっていくのかをシンプルにしてくれ、リアクティブプログラミングを簡単にしてくれるものとして捉えると、自然とライブラリの本質とその根底にある問題領域と解決にたいするアプローチがみえるようになります。
そうすると、どういう場合に使うべきで、どういう場合には向かないのか、あるいはどう書けばより保守として効果の高いコードをデザインできるのかが見えてくるようになると思います。

すなわちRxは本質的にはスタイルを提供するもので、非同期的な処理に関するものは、スタイルを維持するうえで必要だったのです。そしてそのスタイルについて知るには、ちゃんと使ってみるのが大事ですという話でした。

もっと別の例を見てみたいという方はこちらのリポジトリが多少参考になるかもしれません。

github.com