出版業は市場データで効率化できるはず

Amazonは手に入りにくい本が簡単に手に入るのでよくお世話になっている。特に便利だと思うのは、中古本のマーケットプレイスというシステムだ。欲しい本が予め決定しているときに、Bookoffに行くことはない。非常によく出ている本はBookoffで探せば見つかるが、そうでない本がたまたま店舗にある可能性は低い。新本で流通している本は、実店舗で注文することは可能だ。しかし、絶版の本で欲しい本を手に入れるのはマーケットプレイスがなければ難しかっただろう。日本中の中古本がマーケットプレイスで流通しているのだ。かなり珍しい本でない限り、絶版本であってもマーケットプレイスで手に入れることができる。

マーケットプレイスで本を調べていて面白いなと思うことは、中古本の市場がオープンになっていることで、需要と供給で価格が決まっている様子が観察できることだ。マーケットプレイスがあることで、中古本市場の効率性というのが大きく向上しているのだろう。欲しがる人が多くて流通数が少ない本は価格が高いし、逆にベストセラーと言われるような本は数が出ているので価格が低い。

株式市場とかは参加者がグルグル回し合っているからなのか、内部的な運動が大きくて、全く均衡している状態とは思えないが、中古本の市場は投機的な取引がないからなのか単純な需給関係で価格が決まっているように見える。本は状態の差はあれど、中身は同じなので、コモディティであることも市場原理が働く理由なのだろう。新本の価格は再販制度で守られているから、市場というものを感じないが、中古本の価格は市場のリアリティがある。

さて、奇妙だと思うのは、古書とか希少本と呼ばれるようなコレクター性があるものではなくても、まれに絶版本で価格が非常に高いものがあることだ。需要があるにも関わらず、流通数が少ないためだ。何が奇妙だと思うのかというと、出版社はどうして再版しないのかということだ。印刷すれば確実に売れるのに。そういう本を一種類だけ再販しても利益にはならないと思うけれども、数を集めれば結構な利益になるはずだ。

しかし、出版業の商習慣を詳しくは知らないけれども、原稿のデータや出版権を集めてきて、売り出すというのはなかなか難しいことだから実現していないのだろう。インターネット上の公開データという形ではっきりと需要があることが可視化されているにも関わらず、供給ができない現状というのは歯がゆいものがある。出版業は斜陽産業だとずっと言われているが、データに基づいて、工夫すれば延命ぐらいはできそうなのに。

また、街の本屋に関しても、新刊ばっかり入荷して在庫を新鮮な状態に保つのもいいのだけれど、どういう本に需要があるかというのが公開されているのだから、それを利用しない手はない。

中古本の出品数や市場価格を分析したら、いろいろ面白いことが見えて来そうだ。例えば、新刊で発売してから、中古市場に出回るまでのタイムラグが分かれば、新刊が新鮮な状態である期間が分かるだろう。あるいは、出品数が多いにも関わらず、高い価格で推移している本は、きっと新本でも売れるだろう。

また、極端かもしれないが、カスタマーレビューが高い本にウェイトを置いて入荷するという作戦も考えられる。本屋で本を買う行為は、習慣性が強いと思っている。ふらっと入って面白そうなら買う。顧客のロイヤリティっていうのか、一度そういう習慣がついたらなかなか抜けない。本屋で本を買ってそれが面白かったという条件付けができれば、固定客を作れる気がする。

街の本屋からしたら、Amazonは商売敵なのかもしれないが、そこで公開されているデータから、いろいろ試せそうだ。利用できるものは何でも利用したらいいと思う。

Amazonという会社は有益なデータを管理しやすい形で保持していると思うが、そこにアクセスすることは残念ながらできない。どこかにマーケットプレイスのデータを集めて整理して公開しているようなとこはないのだろうか？

コード型ログ(4) Initialization-on-demand Holder

前回：　コード型ログ(3) privateなメソッドのテスト - 超ウィザード級ハッカーのたのしみ

---

必要なときにインスタンスを作ったら、メモリ効率がよくないかと思って変なことをしてしまう悪い例。

class BadSingleton1 {
  private static BadSingleton1 instance;

  // 他の人が勝手にインスタンスを作らないように private にする。
  private BadSingleton1() { };

  static BadSingleton1 getInstance() {
    // 同時に２つのスレッドが null チェックをするとユニークでなくなる。
    if (instance == null) {
      instance = new BadSingleton1();
    }
    return instance;
  }
}

上のようなことをしたければ排他を取る必要がある。しかし、これでは遅い。

class NotBadSingleton1 {
  private static NotBadSingleton1 instance;

  private NotBadSingleton1() { };

  // ユニーク性は保証されるが、同期コストがかかる。
  synchronized static NotBadSingleton1 getInstance() {
    if (instance == null) {
      instance = new NotBadSingleton1();
    }
    return instance;
  }
}

だから、以下のDouble-checked lockingというものが考案された。しかし、実は正しく排他されていないことが知られている。この場合はインスタンス変数がないが、ある場合にはスレッドが競合したときに、getInstance()で返ってくるインスタンスのインスタンス変数が初期化されていない可能性がある。

class BadSingleton2 {
  private static BadSingleton2 instance;

  private BadSingleton2() { };

  static BadSingleton2 getInstance() {
    // instance != null だとしても、インスタンスの初期化が終わっていない
    // 可能性が実はある。
    if (instance == null) {
      synchronized (BadSingleton2.class) {
        if (instance == null) {
          instance = new BadSingleton2();
        }
      }
    }
    return instance;
  }
}

初期化を遅延させたかったら、Initialization-on-demand Holderという名前がついている以下の書き方をする。

class GoodSingleton1 {
  private static class Holder {
    private static GoodSingleton1 instance = new GoodSingleton1();
  }

  private GoodSingleton1() { };

  static GoodSingleton1 getInstance() {
    // Holder クラスが初めて呼ばれたときに、instance は生成され
    // ユニークであることは保証される。
    return Holder.instance;
  }
}

しかし、凝ったことをせずに普通に書いたらいい。

class GoodSingleton2 {
  private static GoodSingleton2 instance = new GoodSingleton2();

  private GoodSingleton2() { };

  static GoodSingleton2 getInstance() {
    return instance;
  }
}

Initialization-on-demand Holderを覚えたからと使いたがる人のコードなんて読みたくない。（私もきっとそういうことをやってるけれども……使わないと覚えないし……）

コード型ログ(3) privateなメソッドのテスト

前回：　コード型ログ(2) staticな変数の排他にはsynchronized(*.class) { } を使う - 超ウィザード級ハッカーのたのしみ

---

privateなメソッドは、ユニットテストがしにくい。

対処法は２つで、

1. テストしないか、
2. Reflectionで頑張るか、
3. スコープをpackage pririveteに広げるか、

である。

呼び出しものの入出力からテストができるのであれば、無理してテストをする必要はない。

しかし、わざわざ別のメソッドに分けたということは、入力と出力の対応が明確な単位になっているはずなので、テストしたい。

Reflectionで頑張る場合は、例えば

class Add {
  private static int add(int a, int b) {
    return a + b;
  }
}

を呼ぶには、

  static int invokeAdd(int a, int b) {
    Method m = null;
    try {
      // getMethod では private メソッドは取得できない。
      m = Add.class.getDeclaredMethod(
          "add", int.class, int.class);
    } catch (NoSuchMethodException | SecurityException e) {
      throw new RuntimeException(e);
    }

    // メソッドにアクセスできるようにする。
    // false の場合は、invoke した際に IllegalAccessException となる。
    m.setAccessible(true);

    int r;
    try {
      // インスタンスメソッドの場合は、第一引数はインスタンスとなる。
      r = (int)m.invoke(null, 1, 1);
    } catch (IllegalAccessException | IllegalArgumentException
        | InvocationTargetException e) {
      throw new RuntimeException(e);
    }

    return r;
  }

というような private メソッド呼ぶためのメソッドを作っておいて、そのメソッドの入出力をテストする。このメソッドは読めないので、何をしたいのかはコメントしておくこと。

これが面倒だという場合は、privateにするのは諦めて、アクセス修飾子をdefault (pacakge private)にして、テストから見えるようにする。その際は、テストの時だけ呼び出して良いことを@VisibleForTestingなどで明記しておく。

VisibleForTesting (Guava: Google Core Libraries for Java 19.0 API)

static, final, private なメソッドはメソッド呼び出しのオーバヘッドをなくすためにインライン展開されることが期待できるが、private なインスタンスメソッドを default にしてしまうとこの効果は期待できなくなってしまうので、final をつけるようにするのがよいかもしれない。効果のほどは未検証。privateとfinalが同じ戦略でインライン展開されるかは疑わしい。

privateであっても、テストの時だけは見えるようになってくれれば良いのだけれど。

public ClassnameTest tests Classname {

とか

@TestFor(Classname.class)
public ClassnameTest {

と書いたら、privateメソッドが見えてくれれば便利なのになあ。

コード型ログ(2) staticな変数の排他にはsynchronized(*.class) { } を使う

他の人が書いていたら読めるけれども、知らなきゃ書けない定型文をあつめたコード型ログを作っている。今回は２回目。

前回： コード型ログ(1) スレッドを止めるにはinterruptを使う - 超ウィザード級ハッカーのたのしみ

---

いい設計とは言えないかもしれないが、staticな変数の排他を取りたい時がある。この場合には、synchronized(*.class) { }を使用する。Classオブジェクトは基本的にはstaticでユニークな、つまりシングルトンなオブジェクトである。*1

package org.example.katalog;

public class SynchronizedClass {
  static int count = 0;

  public void run() {
    Thread[] ts = new Thread[5];
    for (int i = 0; i < ts.length; i++) {

      // count変数の値をプリントして、カウントアップすることを10回繰り返す。
      Thread t = new Thread() {
        @Override
        public void run() {
          for (int j = 0; j < 10; j++) {

            // SynchronizedClass クラスのロックを取る。
            synchronized (SynchronizedClass.class) {
              System.out.println(count);
              count++;
            }

          }
        }
      };

      t.start();
      ts[i] = t;
    }

    for (Thread t : ts) {
      try {
        t.join();
      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    }
  }

  public static void main(String[] args) {
    new SynchronizedClass().run();
  }
}

悪い例は、ロック用のオブジェクトを作ることである。

public class SynchronizedClassBad {
  // ロックオブジェクト
  private static final Object LOCK_OBJ = new Object();
  static int count = 0;

  public void run() {
    Thread[] ts = new Thread[5];
    for (int i = 0; i < ts.length; i++) {

      // count変数の値をプリントして、カウントアップすることを10回繰り返す。
      Thread t = new Thread() {
        @Override
        public void run() {
          for (int j = 0; j < 10; j++) {

            // SynchronizedClass クラスのロックを取る。
            synchronized (LOCK_OBJ) {
              System.out.println(count);
              count++;
            }
// 以下略

なお、staticメソッドにsynchronizedをつけたもの

synchronized static void method() {
  // 処理
}

は

static void method() {
  synchronized (this.getClass()) {
    // 処理
  }
}

と等価である。

*1:ClassLoaderでややこしいことをしたら別。

コード型ログ(1) スレッドを止めるにはinterruptを使う

他の人が書いていたら読めるけれども、知らなければ書けない定型的なソースコードの型を集めているので気が向いたら書いていく。ダジャレが好きなので、コード型ログと呼ぶ。今回は１回目。

---

無限ループを持つスレッドはinterrupt()で止められるようにする。

package org.example.katalog;

public class InterruptSample {
  public static void main(String[] args) {
    Thread t = new Thread() {
      @Override
      public void run() {
        // interruptされるまで、"Hello world"を出力し続ける。
        // なお、isInterrupted()は呼ぶとフラグがクリアされてfalseになる。
        while (!isInterrupted()) {
          System.out.println("Hello world");
        }
      }
    };

    t.start();

    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }

    // interruptするとスレッドのisInterrupted()のフラグが立つ。
    t.interrupt();

    // interruptしてもまだスレッドが止まっているわけではない。
    // スレッドが止まるまで待つ。
    try {
      t.join();
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
}

悪い例は制御フラグを独自につくることである。Javaのスレッドには言語組み込みでその目的のフラグが用意されているのだからそれを使う。

package org.example.katalog;

class HelloPrinter extends Thread {
  // スレッドを止めるべきかのフラグ。
  // volatileはあるスレッドで代入した値が他のスレッドでも
  // 同じものが見えることを保証するおまじない。
  volatile boolean stop = false;

  @Override
  public void run() {
    while (!stop) {
      System.out.println("Hello world");
    }
  }
}

public class InterruptBadSample {
  public static void main(String[] args) {
    HelloPrinter t = new HelloPrinter();

    t.start();

    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }

    t.stop = true;

    try {
      t.join();
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
}

シンプル騎士団を結社する

シンプルであることが設計の最大の美徳ある。これを教義とした秘密結社、シンプル騎士団を結成したいと思う。活動の実体もないし、名簿とかもない。シンプルさって大切だよねと思っている人は、ただ心に思うだけで、特に手続きもなしに構成員になれる。

さて、シンプル騎士団の構成員の一人として、シンプルさについて思うところをについて書く。

シンプルな設計の重要性のついては、しばしば言及される。有名な設計指針として、KISS原則というものがある。"Keep it simple, stupid" とか "Keep it short and simple"とかの略とされる。*1

なぜ、シンプルな設計が重要かというと経済性のためである。シンプルにすればコストが削減される。そして、その効果というのは想像以上となる。複雑性というのは、設計したその時に考えているよりも、ずっと高価である。

最近よく製造業を引き合いに出している気がするが、製造業の経営側の人が言うには「技術者に好きに設計させるとすぐに部品点数を増やしたり、複雑な形にしてしまって製造原価が増える」そうだ。確かにそのとおりで、設計している人には製造するときのコストは分からないものだ。設計図面を引くときのコストと製造するときのコストというのは大きく乖離している。図面で何気なく、穴を一個開けたり、角を丸めたりするのはのは簡単だけれども、実際に金属を削ってその形にするのはコストがかかるものなのです。

機械設計ではシンプルにせよという圧力は非常に強い。一円のコストをかけて良いならもっとマシにできるのにと思いながら、単純にさせられてしまうというのはよくあることだそうだ。実際、自動車も外観とかの仕上げは綺麗だが、下から覗いたら驚くほどの安っぽい作りである。鋳造してちょっと削っただけとか、板をちょっと曲げて溶接しただけとか。

凝ったものを作れるのは軍需産業ぐらいだろう。彼らは好き勝手に高価なものを作っているわけではないが、民生品と比べると驚くようなギミックが付いていることがある。例えば、HEAT弾はたかが弾丸だけれどもびっくりするような複雑さだし、戦闘機のジェットエンジンのノズルはうにうに動く。

しかし、KISS原則はロッキード・マーチン社という軍需産業をしている会社で言われ始めたそうだ。コスト圧力が民需品ほどは高くなくて、放っといたらどんどん複雑化して凝ったものになっていきがちゆえに言われ始めたのかもしれない。

単純にすることで減るのは製造原価だけではない。だから、民需品を作っているところから比べたら原価意識が低いと思われる軍需産業でKISS原則なんて言われたのだろう。シンプルにすれば製造コスト以外のリソースの使用も削減できる。シンプルにすれば、使用性もメンテナンス性も信頼性も向上する。また、思考のコストも減る。凝ったものを作り始めたら、もともと解決したかった問題を忘れがちだ。

問題は、原価以外のコストは見えないコストであることだ。ロッキード・マーチンのスカンクワークスを仕切っていた人は有能だったから、見えないコストも勘定できたのだろうけれども、通常は見えないコストまで考慮されない。製造業の場合は、原価の圧縮がそのまま会社の利益になるので、シンプルにしようという強い動機が働くから、原価以外のコストが見えなくても困らない。

しかしながら、ソフトウェア産業は製造原価がほとんどない。ただデータをコピーするだけだから、複製のコストは限りなく小さい。いくら複雑であろうとも製造原価は変わらない。そのために、複雑性によって生じる見えないコストが見過ごされがちである。

むしろ、製造コストが変わらないのだから、多機能で複雑であるほどよいみたいな風潮さえある。私はこの風潮が非常に嫌いなのだ。この風潮に反旗を翻す人々の集まりがシンプル騎士団である。

ソフトウェアだってシンプルな方がいいに決まっている。

複雑さはすなわち技術的負債だ。デットコードやコピペは資産でもないし、それらをつくることは生産性に含むべきでもない。排除すべきものだ。それらを生み出すLOC生産性なんて殺せ。無意味な複雑さを作ることとか穴掘って埋め戻すだけの作業だ。世の中には一切貢献しないし、ただ他の人の足を引っ張るだけのものだ。

見えないコストも含めた真の経済性を求める人は、ぜひシンプル騎士団に入って欲しい。構成員がすべきことはただひとつだ。シンプルさの維持を、設計の際に大切にすることだけである。

*1:この原則に余計なものがついていたら自身を違反しているので、KISとする場合もある。しかし、その流儀でいうとシンプル騎士団も余計なものを含んでいるとなってしまうので、ここでは採用しない。遊びは必要だと思っている。遊びの余地を作るためにどうでもいいものを削り落とすべきなのだ。

技術者が得意げに解説することこそ解決すべき技術的課題

技術者というのは、製品の仕組みだとか作リ方だとか飼い慣らし方だとかを知っている。それが彼らの自尊心だから、知っていることを得意げに語りたがるし、知らない人を下に見たりする。気持ちはわかるし、誇りを持つことは良いことだ。

ずっとやっていたら詳しくなって当然だ。それが彼らの優位性なので、そこにプライドを持つのは当たり前のことだ。歳月を費やしてわかりにくいものを覚えていったのだ。それをドヤ顔で語るのも無理からぬことだ。

しかし、俺の知っていることはお前らも覚えろと他人に求めても、technologyって何も進歩しないのでないかと思う。

ソフトウェアの歴史は、抽象化の繰り返しだ。人間にやさしくないものに皮をかぶせて、ユーザーフレンドリーに見せかける。それを何十年も繰り返している。

技術者が得意げに語るようなところというのは、まさに皮をかぶせるべきところだと思う。何これ使いづらいなと思って文句を垂れると、なんべんもやって筋トレしてなれろみたいな風に怒られるわけですが、その努力をなくすことがすなわち技術革新だと思う。事実そういう風に技術は発展している。マシンの管理とかめんどくせえと言ったらVMになるし、OSのインストールすらめんどくせえとなったらDockerになるし。

皮を剥いだら現れるようなものも、これ分かりづらいなと思うようなところも、当然ある。分かりやすく書こうなんて風潮は最近のことだから、読めないコードがあっても不思議ではない。読んで分かれと言われたところで、分かりにくいものがそのままなら何の進歩もない。得意げにこれがこうでと説明するなら、そういう風に書き直せばいいのだ。そうしたら、皮の内側を分厚くするもできるし、皮の内側が怪しげなシロモノであることを恐れずに、外に新しく皮を増やしていくこともできる。

めんどくさいとか分かりにくいとかに慣れたら、どうしようもなく古い発想のものしか作れないと思うわけです。これらの感性が使う人の気持ちになれる唯一のヒントだ。低レベルのプログラミングができる人は高レベルもできるとかいう人がいるが、それは嘘だ。レベルを降りるのはできなくもないが、登るのは不可能だ。使う人の気持ちが分からないから。原始的なところとか複雑なところにを潜ってもいいが、傲慢だけ身につけて、怠惰と憤怒を忘れたら、もう帰って来れなくなる気がする。

大して潜ってもいないのに、すでに遭難気味だ。製品の中身は分かるが、使い方は分からないとか言いたくねえな。アプリケーションを、ちゃんと作ったほうがいいのだろうか。