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

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

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

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

Clean Architectureについてメモ

Clean Architecture(以下CA)と
https://github.com/googlesamples/android-architecture
ここに書いてあるブランチのMVP-cleanの実装とはわりと別物。

前者はドメイン層とその外側の境界をちゃんと意識した実装を主張しているのに対して、後者は説明ではCAについてのリンクを貼っているけど、内容はMVPにUseCaseをつけてコマンダーパターンにしただけ。後者は設計の知見が少ないと、簡単にドメイン層に外側の事情が持ち込まれるし、複雑なアプリではかえって冗長性が度を過ぎる場合が多い。UseCaseをつかってRepository(DataSource)にアクセスしてーってところについてはコードの一貫性が心地よい。 そこだけじゃ?

class GetItem extends UseCase<Param, Response> {
    private final ItemRepository repos;
    GetItem(ItemRepository repos) { this.repos = repos; }
    @Override void execute(Callback callback, Param param) {
      Item item = repos.find(param.id);
      item.update(param.value);
      repos.save(item);
      callback.onSuccess(new Response());
    }
}

Googleのサンプルだけを見てうまくできるのはまずCAもちゃんと知っているけど、CAだとファイルが多くなりすぎるから、MVPとDIPを取り入れてみるだけでとどめたいって感じの人なんじゃないかなーと思うと、チームでこれをうまくやるには割とハードルが高い。
あとそのまま低機能なUseCaseHandlerを使うなら、多少学習コストがあがっても枯れているRxJava使った方がいい。 (自分はUseCaseHandlerをキャンセルしこめるようにしたり、Handlerの制御を変えたりと、低機能なやつを改造する方をやったw) ガチでやりたいならCAをちゃんと理解してレイヤーごとにModule化して強制的にDIPなコードにする勇気が必要。
その上でファイルがーって話ならKotlinでやればなんとなく気楽に書けそう。

CAとDDD

DDDの本質はドメインのロジックが、リーダブルでありストラテジックに組みあがっていることを目指すもの。
けどGUIなアプリでは単純にコレクション(DataSource)の出し入れのコードになるので、DDDは結局のところ、Bounded Contextとか戦略的なDDDを適用するで終わってあとはひたすら似たようなことを繰り返すことになる。
特に何かお金や時間みたいな抽象性を利用したライブラリをつくるってわけでもなければ、コード自体は期待したストラテジックには組みあがらない。
CAはドメイン層とその外側との境界を守る方法でDDDとは相性は悪くない。

DDDのストラテジックな表現ってあんまりやるケースがないけど、単純にファイルをクラウドに上げるって感じだと

Content content = MyFileSystem.of(path);
StoreResponse res = Cloud.store(content);
println("rest:" + withByteStr(res.restSize) + " amount:" + withByteStr(res.total))
//とか
ContentList list = MyFileSystem.getNews();
StoreResponse res = Cloud.store(list);
//さすがにフィードバックがないとあれなので
ContentList list = MyFileSystem.getNews();
Cloud.store(list, callBack);

クラウドに上げたファイルをダウンロードって感じだと

Content content = Cloud.getContent(id);
/*
 * パスが指定されていないのは、限定されたパスの直下に配置するという意味で。
 * さらにたとえばキャッシュパスを指定するならMyFileSystem.saveAsCache(content)になる。
 * staticである必要はない。DIをするならなおさらのことstaticではだめだ。ここではあえてDDDとして簡潔なスタイルをとった例として書いている。
 */ 
MyFileSystem.save(content); 
// とか
ContentList list = Cloud.getContentList(groupId, callBack);
MyFileSystem.saveAll(list, callBack2);

GUI関係ない感じだとこんな感じでもいいのかなって。

命名がアレなのはデフォルト。

これをストラテジックな実装の参考にするくらいなら、たしかエリック・エバンス氏が取り上げていた

Eric Evans氏の基調講演より - ドメイン駆動設計を実践するには

ライブラリとしてJoda-Timeや

Joda-Time - Home

氏の書いたライブラリのTimeAndMoneyを参考にした方がいい。

GitHub - neuhalje/TimeAndMoney: Time and Money Code Library

こっちは氏のライブラリ。SourceForgeにあったコードを有志のかたがサルベージしたもの。

プログラミングについて

プログラマーか人間か

僕はプログラマーである自分を人間だと忘れてしまいがちである。 しかし常に僕は人間であることを毎日思い知らされるている。 物理的な制約が、僕をこの社会に縛り続ける。

シンプルになる

人は最適化されるなかで生きていく。 最適化されていなければ、最適化するようにふるまう。 パターンを認識し、不必要な情報はそぎ落とす。 そぎ落とすことで余分なキャッシュをなくし、シンプルになろうとする。

人は同じではない

物事の事象に対する意味の見つけ方は様々で、どう反応するか、反応しないかは、本当に人のいる数だけ違うといっても過言ではない。 これをよく知らないでいると、とんでもない出来事に出くわす。 人は最適化の、シンプルになろうとする上で思い込みを利用する。 過去のパターンにこじつけ、まるで同じものであるかのように、反応する。 しかし、ほとんどの場合そのパターンに当てはまるというのは錯覚であることがすぐにわかる。 しかしシンプルにならなければ人は失敗をする。 このジレンマはいつまでも我々の中で誤解を生み続け、最悪の場合相手を消し去ろうとする。 (最悪は誰のものか?という問題はさておき)

コミュニケーション

人は同じではない、それゆえコミュニケーションが必要になる。 コミュニケーションには、似たようなプロトコルが必要で 地形的な制約による偏在性はそれを可能にした。 長い年月で培ったコミュニケーションのための知恵、知識の伝達は親から子へ受け継がれ。 それゆえの制約も受け入れなくてはならない。 その葛藤のなかで、他者を認識し、他者と同様のプロトコルらしいものがあることを確認する。

言葉

人がシンプルであるために、コミュニケーションという手段をとった。 他者と情報伝達手段の一つのプロトコルとして、形(文字)と声を利用し、言葉という概念を会得する。 言葉を発明した人は、言葉による概念の共有をはじめ、神をつくった。

論理

人は言葉を発展させ論理を獲得した。 論理には人を従えさせる力があった。そして法をつくり、邦あるいは国をつくった。 人はより多くの人のなかで生活をすることが、生きていく上でシンプルさを獲得するには重要であると知った。 人はそれぞれが違うので、より多くの人が集まれば、より多くの人が違いをもたらした。 その結果、論理がより多くの人のシンプルさを保つためのツールとしてつかわれた。 論理はもてはやされ、論理によって文化という概念の上で、論理と文化と文明を発展させていった。

電子制御された機械

論理は測定、記録、発見、発明の効率を上げた。そして科学の進歩を促し、論理自らもさらに発展し、機械が電子制御されるようにした。 機械は複雑な計算をより高速に演算し、情報の持つ価値を飛躍的に向上させるようになった。 電子機械はより小型化されるようになり、より多くの人にとって情報の価値がより上乗せされるようになった。 制御をつど組み替えられるように改造された。 電子機械をプログラムをつかって、より柔軟な演算が可能なように作り替えられていった。

つかれた・・・時系列や因果なんてよくわかんないや・・・何となくそうでしょって感じ

プログラミング

いい加減さっさとプログラミングの説明しろって? イイからもう寝て

良い就職をあきらめてフリーランスになった日

結局のところ、僕は社会不適合者です。

だからフリーランス(のAndroidプログラマー)をやっていると言っていいでしょう。

ここで残念な話だと思う人はブラウザバックでよろしくお願いいたします。

続きを読む