Runner in the High

技術のことをかくこころみ

Pumaのスレッドプールの実装を読んでみる

D言語アプリケーションサーバを書いていて、そういえば普段良く使っているRubyのPumaだと、どういう実装をされているんだろう? というのが気になったので少し読んでみる。

server.rb

まず読み始めるのはPuma::Serverクラスから。 クラスのインスタンス化の際にinitializeの中でスレッド数の下限と上限を変数で保持している。

    ...

    def initialize(app, events=Events.stdio, options={})
      ...

      @min_threads = 0     # デフォルトの最小スレッド数
      @max_threads = 16    # デフォルトの最大スレッド数
      @auto_trim_time = 30
      @reaping_time = 1

      @thread = nil
      @thread_pool = nil

      ...
    end
   
    ...

その数値を元にrunメソッドでPuma::ThreadPoolクラスをインスタンス化し、ワーカスレッドを起動。ブロックに渡ってくる処理は一旦割愛。

最後に、handle_serversでリクエストをワーカスレッドに引き渡す処理を始める。

    ...

    def run(background=true)
      ...

      @thread_pool = ThreadPool.new(@min_threads,
                                    @max_threads,
                                    IOBuffer) do |client, buffer|
        ...
      end

      ...

      if background
        @thread = Thread.new { handle_servers }
        return @thread
      else
        handle_servers
      end
    end

    ...

thread_pool.rb

上で使われているPuma::ThreadPoolクラスのインスタンス化の際には何が行われているのかというと、Mutexで同期をとった上で最小ワーカスレッド数で指定されている数だけスレッドを立ち上げている。

  ...

  def initialize(min, max, *extra, &block)
    ...

    @mutex = Mutex.new

    @todo = [] # ワーカへの処理を積むキュー

    @spawned = 0 # 起動しているワーカの数
    @waiting = 0 # todoを待っているワーカの数

    ...

    @min = Integer(min) # min_threads
    @max = Integer(max) # max_threads

    ...

    @workers = [] # spawn_threadで起動されたワーカのアレイ

    ...

    @mutex.synchronize do
      @min.times { spawn_thread } # ワーカスレッドを起動
    end

    ...
  end

  ...

spawn_threadはちょっと長いが、中で行われているのは、whileでのスレッドの処理ループだ。

initializeの中で初期化された@todoというインスタンス変数にワーカへの処理が積まれていくので、ワーカが起動している間(continueがtrue)は、todoに積まれているキューをshiftして、スレッドに渡されているブロックで実行している。また、todoが空っぽの際はThread::ConditionVariableでスレッドをストップさせている。

また、作られたワーカスレッドは@workersに追加される。

    ...

    def spawn_thread
      @spawned += 1

      th = Thread.new(@spawned) do |spawned|
        ...

        todo  = @todo

        ...

        while true
          work = nil
 
          ...

          mutex.synchronize do
            while todo.empty? # ワーカが処理するものは何もない
              ...

              @waiting += 1
              not_full.signal
              not_empty.wait mutex # todoが入ってくるまでスレッドを止める
              @waiting -= 1
            end

            work = todo.shift if continue # todoからひとつもらってworkにいれる
          end

          ...

          begin
            block.call(work, *extra) # workの処理をスレッドに引き渡す。
          rescue Exception => e
            ...
          end
        end

        ...
      end

      @workers << th # 作ったワーカスレッドを追加

      th
    end

    ...

Puma::ThreadPoolには<<のオペレータが定義されていて、インスタンスtodoを積み、スレッドを動かせるようになっている。

また、積む際に待っているワーカがいなければ、再び上で触れたspawn_threadを実行して再び上限までワーカスレッドを起動しようとする。

  ...

  # Add +work+ to the todo list for a Thread to pickup and process.
  def <<(work)
    @mutex.synchronize do
      ...

      @todo << work

      if @waiting < @todo.size and @spawned < @max
        spawn_thread
      end

      @not_empty.signal # 空ではなくなったことを通知して、スレッドを動かす
    end
  end

  ...

ちなみに、この<<オペレータは一番最初に触れたPuma::Serverクラスの中にあるhandle_serversメソッドの中で使われていて、ソケットで受けたリクエストからPuma::Cilentクラスのインスタンスを生成し、その処理をスレッドプールに任せるために使われている模様。

    ...
   
    def handle_servers
      begin
        ...

        pool = @thread_pool

        ...

        while @status == :run
          begin
            ios = IO.select sockets
            ios.first.each do |sock|
              if sock == check
                ...
              else
                begin
                  if io = sock.accept_nonblock
                    client = Client.new io, @binder.env(sock)
                    ...

                    pool << client # スレッドプールへtodoを積む
                    pool.wait_until_not_full
                  end
                rescue SystemCallError
                  ...
                rescue Errno::ECONNABORTED
                  ...
                end
              end
            end
          rescue Object => e
            ...
          end
        end

        ...
      rescue Exception => e
        ...
      ensure
        ...
      end

      ...
    end

    ...

そういえば、起動されたワーカが必要なくなったときの処理はどうしているんだろう? と思ったら、trimというメソッドがPuma::ThreadPoolクラスの中にあるのを見つけた。このメソッドの中では待ちワーカがひとつ以上あり、かつワーカの数が下限を下回らない範囲で、ワーカスレッドを終了させるキュー(trim_requested)を加算していく。

    ...

    # If too many threads are in the pool, tell one to finish go ahead
    # and exit. If +force+ is true, then a trim request is requested
    # even if all threads are being utilized.
    #
    def trim(force=false)
      @mutex.synchronize do
        if (force or @waiting > 0) and @spawned - @trim_requested > @min
          @trim_requested += 1
          @not_empty.signal
        end
      end
    end

    ...

@trim_requestedが加算されていくと、todoが空っぽの際にワーカスレッドが自ら終了していく。この処理は上で触れたspawn_threadの中のワーカスレッドの処理ループの中で行われている。

    ...    

    def spawn_thread
      @spawned += 1

      th = Thread.new(@spawned) do |spawned|
        ...

        todo  = @todo

        ...

        while true
          ...

          continue = true # ワーカスレッドを起動し続けるかどうか

          mutex.synchronize do
            while todo.empty?
              if @trim_requested > 0 # 終了がリクエストされている
                @trim_requested -= 1
                continue = false # ワーカスレッドの終了をセット
                not_full.signal
                break
              end

              ...
            end

            ...
          end

          break unless continue # ワーカスレッドの処理ループを抜ける。

          ...
        end

        mutex.synchronize do
          @spawned -= 1      # 動いているワーカの数をひとつ減らす
          @workers.delete th # ワーカのアレイから削除
        end
      end

      @workers << th

      th
    end

    ...

Puma::Serverクラスのrunメソッドは、ワーカスレッドを起動するのと同じタイミングで、デフォルト30秒のインターバル(@auto_trim_timeで指定されている)毎にtrimメソッドを呼び出すPuma::ThreadPool::AutoTrimクラスのインスタンスを準備する(auto_trim!

    def initialize(app, events=Events.stdio, options={})
      ...

      @min_threads = 0
      @max_threads = 16
      @auto_trim_time = 30 # auto_trim!のインターバル
      @reaping_time = 1

      ...
    end

    ...
   
    def run(background=true)
      ...

      @thread_pool = ThreadPool.new(@min_threads,
                                    @max_threads,
                                    IOBuffer) do |client, buffer|
        ...
      end

      ...

      if @auto_trim_time # インターバルが指定されていれば、auto_trimを始める。
        @thread_pool.auto_trim!(@auto_trim_time)
      end
      
      ...
    end

Puma::ThreadPool::AutoTrimクラスは@timeoutで指定されたインターバル毎に、Puma::ThreadPooltrimメソッドを呼び出して余ったワーカスレッドの終了を試みる。

    ...

    class AutoTrim
      def initialize(pool, timeout)
        @pool = pool
        @timeout = timeout
        @running = false
      end

      def start!
        @running = true

        @thread = Thread.new do
          while @running
            @pool.trim
            sleep @timeout
          end
        end
      end

      ...
    end

    def auto_trim!(timeout=30)
      @auto_trim = AutoTrim.new(self, timeout)
      @auto_trim.start!
    end

    ...

Pumaでは、Puma::ThreadPoolクラスが、ワーカスレッドと、ワーカへの処理のキューを管理していて、キューが予約されるタイミングでワーカを増やしたり、減らしたりしているということが分かった。

今回は、スレッドプールの部分を中心に読んだだけなので、実装にリクエストをどう処理しているのか、クラスタリングの実装はどうなっているのか、あたりはまだしっかり読んでいない。けれども、既存のアプリケーションサーバの実装を読んでみることで、自分で1から作っていく際にどういう実装にするのがベターかというプラクティスを探るきっかけになりそうだな〜と思う◎

D言語でforkを使う

core.sys.posix.unistdの中にある。使い方はforkそのまま。

import std.stdio;
import core.thread;
import core.stdc.stdlib;
import core.sys.posix.unistd;

void main() {
  auto pid = core.sys.posix.unistd.fork();

  if (pid == 0) {
    writeln("child working...");
    Thread.sleep(dur!("seconds")(10));
    _Exit(0);
  } else {
    writeln("parent working...");
    Thread.sleep(dur!("seconds")(20));
    exit(0);
  }
}

ちなみに親プロセスを終了するときはexit(0)で、子プロセスを終了するときには_Exit(0)で抜ける(どちらもcore.stdc.stdlibの中で定義されている)。この2つの関数の違いは、標準入出力のデータを終了時にフラッシュするかしないか、というところらしい。

exit()と_exit()の違い | Siguniang's Blog

D言語でstd.signalsを使ったオブザーバー実装

std.signalsというモジュールを使うとオブザーバー・パターンの実装が簡単にできる。 この例ではひとつのオブザーバーしか登録していないが、複数のオブザーバーを登録した上で一気にシグナルを発行できる。

dlang.org

import std.signals;
import std.stdio;

enum SignalTypes {
  INCREASE,
  DECREASE
};

class SignalObserver {
  private int signalCounter;

  this() {
    signalCounter = 0;
  }

  void watch(SignalTypes type) {
    switch (type) {
      case SignalTypes.INCREASE: signalCounter++; break;
      case SignalTypes.DECREASE: signalCounter--; break;
      default: break;
    }
  }

  @property int counter() const {
    return signalCounter;
  }
}

class SignalTrigger {
  void update(SignalTypes type) {
    emit(type);
  }

  mixin Signal!(SignalTypes);
}

__gshared SignalTrigger trigger = new SignalTrigger();
__gshared SignalObserver observer = new SignalObserver();

void main() {
  trigger.connect(&observer.watch);

  trigger.update(SignalTypes.INCREASE);
  trigger.update(SignalTypes.INCREASE);
  trigger.update(SignalTypes.INCREASE);

  writeln(observer.counter); // 3

  trigger.update(SignalTypes.DECREASE);
  trigger.update(SignalTypes.DECREASE);

  writeln(observer.counter); // 1
}

D言語でCtrl-Cのシグナルハンドラを登録する

whileループからCtrl-Cで抜ける処理を横取りしたいときに。

import std.stdio;
import core.thread;
import core.stdc.stdlib;
import core.sys.posix.signal;

extern (C) {
  void cleanup(int signal) {
    writeln("cleanup");
    exit(1);
  }
}

void main() {
  sigset(SIGINT, &cleanup);

  while (true) {
    writeln("waiting...");
    Thread.sleep(dur!("seconds")(1));
  }
}

ポイントはクリーンナップコードをextern (C) { ... }の中で定義することと、integer型の引数を与えること。 SIGINT以外にもいろいろハンドラが登録できるっぽい。ちなみにちゃんとexitしないと、killコマンドで殺さないといけなくなるので注意。

github.com

10月にしたLTまとめ

 唐突に、この10月にした4つのLTに関して振り返ってみようと思う。

 これまで自分は勉強会などでいわゆるライトニング・トークというものをしたことがなかったが、内定先の師匠と話をしていてちょっと試しにやってみるのも悪くはないなと思い始めたのがきっかけだった。仮になにかテキトウなことをLTの中で話してしまったとしても、まさか命までは取られまい、という思いでえいやとやってみようと思ったのだ。

Meguro.rb #7

 これはちょうど直近で参加できそうなRubyの勉強会を探していて、初めて参加したMeguro.rbでのLT。
 ROMと呼ばれるヘキサゴナル・アーキテクチャで実装されたデータ・マッパー・パターンの永続レイヤのライブラリについて話した。普段は僕もRailsActiveRecordをガンガンに使っているが、ドメインモデルと永続化の責務を分割したいと思うならROMという選択肢も充分にありえるのではないかと思う。ROMの思想を一番よく表しているのが、永続化レイヤをDBだけのものとして考えず、WebAPIへのリクエストなども永続化の責務としてアダプタブルにできるものとして扱う、という点で、レイヤード・アーキテクチャが好きな僕としてはとても感動した。
 これが人生で初めてのLTだったので、割と早めに資料を作ってちょいちょい練習っぽいこともした。何事も初めてであれば練習をしすぎるということはない。参加者のひとたちも、発表が終わったあとに話しかけてくれたりして、初めてのLTとしてはいいスタートを切れたと思う。

WEBエンジニア勉強会 #3

 WEBエンジニア勉強会も、connpassで何かLTができそうな手頃な勉強会がないかなと探していたときに見つけた勉強会のひとつだ。この第三回目は新橋のコワーキングスペースで開催された。
 このスライドは、フロントエンド・アプリケーションにおけるバリデーション・ロジックの責務をどこにおくのか、という問題提起をしてみたくて作ったスライドだ。基本的に、フロントエンドのバリデーションというと、ビュー側に意識が寄ってしまうことが多い。なぜなら、バリデーションというのは、バリデーション自体のロジックと、そのエラーの表示というものがワンセットになっていると考えがちだからだ。だが、アプリケーションの種類問わず、バリデーションというのはビジネス・ルール含むことが多く、基本的に「バリデーションを実行する」という責務はドメイン・レイヤに置き、「バリデーションのエラーを表示する」という責務のみをビューに置くのが最適解なのではないかと僕は考えている。
 そのような趣旨でこのスライドを作ってはみたものの、実際に勉強会に来てくれているひとたちのなかにフロントエンド開発をしている人がさほど多くなかったので、次回からはもう少し勉強会に併せて話す内容を工夫したほうがいいかもな、という反省を得た。

 ちなみにではあるが、上のスライドで登場するvalidatable-recordはnpmで公開してある

www.npmjs.com

izumisy-tech.hatenablog.com

第12回若手Webエンジニア交流会

 知り合いのiOSエンジニアが主催していた勉強会を偶然connpassで見つけたのでここもLT枠で突撃した。仰々しいタイトルだが、僕のスタックオーバーフローのREPは500程度しかない。この勉強会は開会と同時に飲酒開始なので、LTも非常に気持ちよく話せてとてもエキサイトした。発表が終わったあと、すごくおもしろかった!的な声を数人から頂いて、やはり「トピックx話し方」でLTのウケは結構変わるんだな〜とも思った。あと酒を飲むと非常に饒舌になれるので、シャイな自分はあらかじめ酒をちょっと入れておくというイイということを学んだ。
 このスライドはもともと、僕が今年に入ってからスタックオーバーフローでいくつか回答をし始めて、思ったよりもREP稼ぐハードルって高くないんだな!と思ったところからアイデアを得た。スタックオーバーフローというと外国のすごそうなエンジニアがじゃぶじゃぶいるようなイメージだが、実際には我々日本人の英語力であれば全くコミュニティに貢献できること間違いなしだ。僕でもできるからみんなでやろう、という意気込みをぶつけるスライドだ。
 ちなみに参加者の中にJapanese Languageで4000REPくらいもっているという人がいて、ヒエ〜となった。是非そういう人からより具体的なREP稼ぎのノウハウを聞いてみたいものだ。

第33回 PORTもくもく会

 おととしのインターンで知り合った三人でちょっとした開発チームのようなものを組んでいるので、僕含めその三人でLTをしようとこのもくもく会に参加。会場は新宿にあるでっかいビルだった。
 これまでの勉強会と比べて集まっている人たちがほんとに様々で、Vimプラグインをめっちゃ作っている人や、Rubocopのコントリビューター、自分の本を書いている人、などなど思ったより幅広かった。そこで僕がしたLTがchooというウェブ・フロントエンド・フレームワークに関するものだったが、そもそもまたフロントエンドを触っている人がそんなにいないということもあり、ウケが微妙だった。
 このLTでchooを取り上げた理由は、chooはフロントエンド・フレームワークの中でも関数型プログラミングの雰囲気を持つように設計されていて、いわゆるVue.jsやReactで言うところのコンポーネントが、chooにおいては純粋なDOMを返す状態を持たない関数となるように実装できるというところが好みだったからだ。
 フロントエンドにおける「状態」はもはやコンポーネント単位のステートという形で責務分けするのではなく、ビューから切り離された状態というそれ自体の責務になるほうが、スケーラビリティがある。この考え方をすれば、そもそもビューを「ステート→DOM」の単なる変換に専念させられるし、ビューとステートが密結合になりづらくなる。なお、この話関しては別の記事で書いたのでこちらを参照のこと。

izumisy-tech.hatenablog.com

4回LTしてみて

 LTをする前は、まだまだ僕には話せることなんてそんなにないと思っていたけれども、実際にLTに申し込んでスライドを作り始めると、思った以上に話すことがでてきたり、なにより人前でマイクを持って話すのがわりと興奮(?)したりするということが分かった。Twitterで誰かが、「まずLTに申し込む。アイデアはあとからでてくる。」と言っていたのを思い出して、ん〜たしかにそのとおりだった、と思う。
 とはいえ、勉強会によっては参加者の層的にあんまりLTの内容が伝わらなかったりすることがあるので、そういう点でもみんながわかりやすい/共感しやすいLTがこれからはできていけたらいいなという所存。いつかはでっかいカンファレンスとかで発表ができるといいな。

10月のOneTapBUY

 先月書いていたOneTapBUYに関する記事から少し評価額で変化が合ったのでちょろっとだけ記事にしようと思う

f:id:IzumiSy:20171026181216p:plain:w300

 前の段階では3000くらいの利益だったが、とうとう10000を切り始めた。投資額から見てこの伸び幅がすごいのかすごくないのかはわからないが、12万で1万の利益が出るような金融商品はあまり他にはなさそうなので、これはこれでいいパフォーマンスだと思う。とはいえ僕個人は株のプロフェッショナルでもなんでもないので、とりあえず「伸びがありそうな株」と「配当がそこそこでそうな株」の2軸だけに絞ってVISA, XEROX, INTELの3つに投資している。VISAは長期的に見て必ず上がり続ける株のようなので、配当は関係なくとりあえずだらだらと長期的な保有を考えている。

 とはいえ、おそらくOneTapBUYで選べる株式のほとんどどれもが、長期的に持っていればこれくらいのパフォーマンスをだすものなんではないかな、と思う。それは、OTB指数というもののパフォーマンスで分かる。

onetapbuy.hatenablog.com

 余談だが、つい最近クラウドバンクも始めた。いまのところ投資額はOneTapBUYと同じくらいだが、パフォーマンスで言うと年6〜7%といったところらしく、さほどリスキーではなさそうな利幅でよろしいと思う。こちらもどういう風にお金が増えるのか楽しみだ。

SAMパターンの大雑把な理解

 SAMパターンというのを勉強している。

www.infoq.com

 この記事は少しだけはてブでバズったが、実際コレを読んだだけでは例えば実際に実装に落としたときにどういうデータ・フローになるのか、というところまでは若干理解しづらい。この記事の作者のDubrayはsam.js.orgでいろんなサンプルコードを紹介しているので、それらを参照すると若干理解が捗る。

 ちなみに今のところ自分の中で整理しきれた雑なSAMのデータ・フローはこれ。

f:id:IzumiSy:20171014171004j:plain

 パッと見の雰囲気はFluxアーキテクチャと全く違う、という感じではない。SAMはState-Action-Modelのアクロニムで、ベースになるのもその3つの要素だ。それぞれの要素の名前はこれまでのアーキテクチャを知っている人からすると、比較的馴染みやすいものではあるかと思うが、SAMの場合はそれぞれが担う責務が若干異なる。なので、たとえばStateと聞いたときにそれが何を意味するのかというのは、既存のアーキテクチャの考え方からではなく、SAM独自の考え方から理解するのがよい。

 ということで、SAMにおける主要な3つの要素に焦点をあてて、sam.js.orgでの解説を元に、簡単な責務の説明をしてみたいと思う。

Model

 SAMにおけるModelとは、Actionから受け取った計算結果を保持し、それをビューに反映させるトリガを提供するだけの存在だ。すなわち、ここにはドメインロジックなどは一切入り込まない。

The model contains all the application state and (logically) exposes a single method: present(data)

 上のデータ・フロー図ではModelの中にPresentという関数がいるが、これがModelの唯一持つ関数としての責務だ。Presentが行う大きな責務は、フロントエンド・アプリケーションで言うところのレンダリング処理のトリガだ。現在の状態を元に、ビューに状態を反映させるトリガをキックする。また、そこで使われる「現在の状態」は全てModelが持っている。

The model is also solely responsible for the persistence of the application state.

 加えて、この説明が示すように、Modelはデータの保持の責務(Fluxで言うところのストア)も持っている。SAMは単なるアーキテクチャのため「メモリに載せる」「localStorageを使う」などの、どう永続化するかという「方法」の点では一切の言及がない。この責務をどう実装するかという点は自由だ。

Action

 SAMにおけるアクションは、データを受け取り、そのデータをもとに実行したビジネスロジックの結果をModelへPresentを介して送りこむ関数だ。Actionのトリガはビューと、後述するNAPによって行われる。

Actions are responsible for implementing context specific logic.

 SAMパターンにおいて、Actionとはドメインモデルに対する操作を行う場所だが、実際にここをどう実装するかに対する方針はSAMでは言及されていない。再利用可能なドメインモデルに具体的な操作は委譲し、ここではそれらのビジネスルールを用いて得られる結果のみをモデルに対して送るというのがおそらく良いかと思われる。

In the context of SAM, actions play another important role with respect to invoking 3rd party APIs.

 加えて、ActionはAPIコールなどを行う場所でもある。

State

the State does not hold any “state”, it is a pure function which computes the view and the next-action predicate, both from the model property values.

 SAMにおけるStateはFluxアーキテクチャのそれとは異なる。Reduxを使っている人なら、Stateと聞くとストアの中にあるデータ構造のことをイメージするかもしれないが、SAMの場合にはStateの具体的な責務は、Modelが保持しているデータ構造と、ビューで必要とされるデータ構造間のインピーダンス・ミスマッチの解消に近い。StateはModelから受け取ったデータを元にビューで必要となるデータに変換を行う関数でしかない。

the State is responsible for invoking the next-action predicate (nap)

 NAPはNext-Action-Predicateのアクロニムで、Stateが持つもう一つの責務を指すもの。これは、見方を変えればStateの副作用だ。NAPは現在のModelの状態から、次にトリガされる必要のあるActionを呼び出す。sam.js.orgのStateセクションでは、ロケット発射台のプログラムが例になっている。ロケットのカウントダウン・カウンタを減算していくActionがあり、そのアクションによってカウンタが0になったとき、Modelの状態を見て自動的にロケット発射のActionをトリガする。

 NAPの利点は、ビューを単なるStateの写像にするために、特定条件下でトリガされるアクションの条件分岐という責務をビューから取り払うことができるという点だ。Fluxアーキテクチャにおいて、Actionの発火元は常にビューだったため、例えばswitch文で記述される状態に関連したアクションの発火(たとえば状態を見てナビゲーターによって遷移を起こさせるなどのロジック)をビューに記述していく必要があった。これは場合によってはビューの肥大化につながることもあるが、SAMはNAPによってビューからそのような責務を分離している。

まとめ

 SAMパターンが最も意図しているところは簡単で、ビューがアプリケーション全体に影響を及ぼすことがないようにしよう! というだけのことだ。そのために様々なMVCやらMVVMやらが考案されてきたが、SAMはより関数型のアプローチをしようとしているアーキテクチャだということが分かる。ほとんど日本語の資料がないので、少しづつSAMの公式ページを読んでいくしか今のところ学ぶ手段はないが、それでも充分読んで見る価値がある。

 また、大事なことはSAMというフレームワークやライブラリがある、ということではないということだ。つまり、SAMというアーキテクチャに関して、どう実装するかは十人十色だ。実装にReactを使うのか、それともChooかVanillaJSか、という点はSAMにおいてはまったく重要ではない。大事なのはアーキテクチャとしての考え方だ。

 とはいえ、InfoQで掲載された記事についているぶコメは、記事を読んでそうに見えて、いくつかはあんまり関係のないものがあった。「サンプルコードでXSSできるから微妙なのでRedux使っとこう」「ナマのJSで良いという主張だということが分かった」「htmlを文字列連結で書くなんて」というあたりのコメントだが、これはおそらくアーキテクチャ自体ではなく、それを実現するために使う言語やツール、すなわち「手段」に関して興味が寄りすぎている。

 手段それ自体への興味はとても良いが、あまりにそこへ指向の比重が寄りすぎてしまうと、どうしても手段が設計に影響を及ぼしかねない。アプリケーションを作るにあたって、手段がなにかを規定してしまうのは大抵の場合よくない。技術をやっていると、どうしてもそこが面白くなってしまうことが多いが、一歩身を引いて設計という観点からものを見直すというのは、いつでも重要なのではないかと思う。

Yeomanに代わるNode.jsのスキャフォルディングツール4選

 ハッカソンや個人開発でよく使う自分でこしらえたアプリケーションのスケルトン・コードをGithubに置いて、それを気軽にスキャフォルディングしたい。こんな欲求はだれしもあると思う。スキャフォルディング・ツールの王道といえばYeomanだが、ちょっとYeomanは...という人は少なくない。ということで、今回の記事では、Yeomanの代替になるような、Node.js製のスキャフォルディング・ツールを紹介しよう。

khaos

f:id:IzumiSy:20171012230404p:plain:w500

GitHub - segmentio/khaos: A super-simple way to scaffold new projects.

  • segment.ioが作っていたシンプルなGithubレポジトリベースのスキャフォルディングツール
  • 機能が小さく纏まっており、マスタッシュ記法をサポートするスキャフォルディングができる
  • テンプレート中のマスタッシュから、CLIが勝手に入力項目を指示してくれるので、設定ファイルなどが不要。
  • ほぼメンテされてないっぽいのが気になる

slush

f:id:IzumiSy:20171012230712p:plain:w150

GitHub - slushjs/slush: The streaming scaffolding system - Gulp as a replacement for Yeoman

  • gulpを内部で使っているYeomanの代替を目指した大型スキャフォルディングツール
  • http://slushjs.github.io/generatorsに使えるテンプレートがリスティングされている
  • テンプレートになるslush-xxxというnpmをグローバルにインストールしないといけないのがちょっとイヤ
  • プロジェクト生成時に新しいディレクトリを作ってくれないという罠がある(これはいいのか?)
  • 使い勝手は(おそらく)Yeomanと近い。

pollinate

f:id:IzumiSy:20171012231207p:plain:w400

GitHub - howardroark/pollinate: Template your base files and generate new projects from Git(Hub).

  • この中でもわりとイチオシのGithubレポジトリベースのスキャフォルディングツール
  • 機能的にはsegment.ioのkhaosと近いが、こちらのほうが高機能
  • template.jsonというファイルをテンプレートのレポジトリに配置することで、スキャフォルディング時に無視するファイルや、ファイルのリネームなどができる
  • シンプルながら、汎用性が高くてよい◎

degit

GitHub - Rich-Harris/degit: Straightforward project scaffolding

  • マスタッシュ記法によるテンプレート化などを一切サポートしないGithubベースのスキャフォルディングツール
  • クローンせず、ただレポジトリをダウンロードするだけなので非常に高速
  • 作者「git clone --depth 1でもいいけど.gitディレクトリがついてきたりするから、こっちのが良いぜ」
  • テンプレート化とかとにかく考えないでリポジトリをスケルトンとしてつかうんや!みたいな用途には最適っぽい

(番外編) cooking

f:id:IzumiSy:20171012231647p:plain:w170

cooking - 更易上手的前端构建工具

  • 毛色が違うがslushのテンプレートを探していて見つけたので最後に紹介
  • webpackを使うフロントエンド・アプリケーションの開発に特化したスキャフォルディングツール
  • slushのテンプレートを検索していると、slush-cooking-xxxというのがでてくるが、それがcookingのテンプレート
  • cooking initを実行するとデフォルトでslush-cooking-vueが指定されたり、ナチュラルに中国語が出てきたりするので挙動がよくわからないときがあるが、そのあたりさえ割り切れればわりと使いやすそうな雰囲気がある

まとめ

  • おそらくこの中で使うならdegitとpollinate
  • 特にpollinateは機能面ですごく申し分ないし、それにロゴも緑のエコロジーな感じで○
  • プライベート・リポジトリ対応などは調べていないが、どのツールもあまり望めないと思われる