Runner in the High

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

D言語で作るTCPサーバの最小構成

コネクションプーリングとかワーカスレッドの多重化とかやってないめっちゃ簡易版。

import std.stdio;
import std.socket;
import core.thread;

void main() {
  Socket server = new TcpSocket();

  server.setOption(SocketOptionLevel.SOCKET, SocketOption.REUSEADDR, true);
  server.bind(new InternetAddress(8080));
  server.listen(1);

  char[1024] buffer;

  enum header =
    "HTTP/1.0 200 OK\nContent-Type: text/html; charset=utf-8\n\n";

  string response = header ~ "Hello World!\n";

  while(true) {
    Socket client = server.accept();

    client.receive(buffer);
    writeln(cast(string)buffer);

    client.send(response);

    client.shutdown(SocketShutdown.BOTH);
    client.close();
  }
}

なんらかの処理において、できるだけその処理は依存するモデルのデータ構造をしりすぎないほうがよい?

  • たとえばSPAにおいて 「あるカテゴリに紐づく記事一覧を取得する」 という実装があるとする

  • このような処理を実装するにあたっては、各レイヤによって知ってよいことと、知っててはいけないものが変わってくる。

  • 例えばバックエンドが、RDBMSのようなIDによってデータを区別するようなミドルウェアを使っているのであれば、むろんAPIの呼び出しなどを行うデータアクセス・レイヤへアプリケーションが保持しているエンティティのIDがなんらかの方法で渡ることになるが、以下のように明示的にデータ構造がIDという属性を持っているということを期待している(=知っている)ようなコードを書くのは良くないと思っている。

const articles = fetchArticlesByCategoryId(category.id)
  • この実装を自分が改善するとしたら、以下のようにする
const articles = fetchArticlesByCategory(category)
  • この改善によって、fetchArticlesByCategory はもう category のデータ構造を知る必要がなくなった。これは、 category のデータ構造の変更が発生したとしても fetchArticlesByCategory を使うレイヤは影響を受けない(=変更に強い)ことを意味する。

  • fetchArticlesByCategory はその名前から分かるようにリポジトリ・レイヤの責務なので、リポジトリcategory などの依存するドメイン・モデルのデータ構造を処理の中で知識として持っていることは問題ない。バックエンドの仕様が変わってIDの代わりにカテゴリ名でフィルタするようになりました! みたいになっても、リポジトリ・レイヤだけ弄ればよいので、ドメイン・レイヤは変更から守られる。

  • もっと言うと、ドメイン・レイヤの中に id みたいなインフラ・レイヤを感じさせるような言葉が出てくるのがすでに危険信号のように見える。それとも id がインフラ・レイヤを感じさせる、というのは自分がRDBMSのことを考え過ぎなのだろうか...

  • ちなみにこの記事は書いててデメテルの法則だな〜と思った。

2017年を振り返る

 振り返ります

1月

  • 丁度大学の後期の期末試験を受けていた。2016年夏頃(後期)から大学に復帰したので、そのテストを消化してた。都市社会学のレポートを書くのに清澄白河をウロウロして写真を撮った記憶がある。ジェントリフィケーションについて書いた。それから、まだこの頃は教職課程のガイダンスなどがいくつかあって、このあとすべての努力が無駄になるとは知らずに頑張っていた。

  • 初めて渋谷WOMBへ行って、Zomboyを生で見た。Zomboyもスゴかったが、ぎゅうぎゅう詰めすぎてびっくりした。 www.womb.co.jp

2月

  • 大学の先輩と同期と一緒にスノボをしに竜王スキーパークへ行った。中級者コースから初心者コースのふもとのリフト乗り場まで一直線で滑るとめちゃくちゃ距離があって気持ちいので、最高のスキー場だと思う。それから、中級者コースの途中にある滑っていかないと入れないレストランのタコライスがすごくおいしい。ここでタコライスを食べてからタコライスにドハマりしはじめた。 www.ryuoo.com

3月

  • 内定先の開発合宿に参加した。どこに行ったかは忘れたけど、すごく天気がよくて山のたくさんあるところに行った。

  • 一年休学していた僕より一足先に大学の同期達が卒業していくので、サークルの卒業旅行でグアムへ行った。なんてことはなかったが、海で日焼け止めをちゃんと塗ってなかったせいで、全身大やけどを負い、赤く腫れて水ぶくれたような症状に僕を含めて男子三人がなった。死ぬかと思った。夜寝てても、歩いてても、何をしててもヒリヒリ痛い。飛行機はガタガタゆれるし椅子に背もたれがあるしで、痛くて痛くてしょうがない。帰国してから速攻で近くの皮膚科にいくと、コワモテのオネエの先生が優しく診て塗り薬を出してくれた。それからは少しづつ完治していったが、もう南国はこりごりだという気分になった。それでもグアムは基本的に気温も天気も最高で、場所としては申し分ない。でももうビーチで裸にはなりたくない。

  • この辺から内定先でAPJというものが始まる。これは技術職の内定者と総合職の内定者がチームを組んで、ひとつのAndroidアプリを作るというもの。基本的にコードを書かない側の人間であっても、技術に少しでも触れる経験をするというコンセプトらしい。僕らは、位置情報を利用したSNSのようなものを作ることにした。

4月

  • Junction Asiaに参加した。会場は寺田倉庫だった。僕らは4人1組のチームで参加して、顔認証から悪質な訪問販売などをブラックリスト化するインターフォンのようなものを開発したが、惜しくも賞は取れなかった。久しぶりに1泊2日のハッカソンに参加したが、2日目の朝のあのしんどい感じはいつ経験しても慣れない。

  • 1年生のころから少しづつ教職課程の単位を取りづつけていたが、取得単位の関係でこの年の5月ないし6月に予定されていた教育実習にいかせることはできないという通告を教職課程事務局から受ける。というのも、僕が1年間の休学をしていたことによって、卒業に必要な単位と教育実習へ行くのに必要な単位の講義が2017年度の授業予定で重複してしまったからだ。教職課程事務局はすでに僕がとっている単位から、必要科目として認定単位の振替をできるかもしれないとかなんとか言っていたが、それに関してはなんの処置も行われなかった。最終的には、教職課程を辞退する紙にサインをさせられ、それまでに取ってきた教職課程の単位をすべてフイにすることになった。武蔵大学には、休学をしようが留学をしようがまともに4年間で卒業ができるようなキャリアパスをしっかり用意してもらいたいと思う。

5月

  • 卒論のことを考え始める。

  • 3月から始まったAPJの遠隔ミーティングを頻繁にし始める。

  • 高校の頃に軽音楽部にいた後輩が意識の高い学生になっていて、ミクシィインターンをしているというので渋谷で食事をした。話を聞いてみると、軽音楽部に所属していたまた別の後輩が、スタートアップ界隈で活動をしていて、それにいろいろと影響を受けたらしい。人間どこでどう変わるかわからないものだなと思う。

  • この頃からなぜか急に思い立ってStackoverflowでスコアを伸ばそうとし始める。5月の時点で303ポイントまで上げた。

6月

  • 内定バイトを始める。ReactNative+TypeScriptを本格的に触り始める。

  • 卒業論文の題目を決める時期なのだが、こんなタイミングでテーマが決まるはずがなく、適当なテーマで提出する。アメリカのスタートアップカルチャーについて書きたいなと思っていたが、先行研究がなさ過ぎて頓挫する。

  • 2015年夏のインターンの知り合いが東京の大学院に来たということで遊びに行ったが、そのタイミングで新たなプロジェクトがスタートする。

  • 内定先の会社が上場する。東京証券取引所に行って鐘を鳴らす場面を生で見た。

7月

  • 軽井沢に旅行に行った

  • 3月から本格的に始まっていたAPJが終わる。位置情報を利用したSNS的なもの、という感じでそれっぽいものを作ったが、あまりいい評価は得られなかった。我々の他には、社内の技術本を貸し借りするためのアプリや、成分表の写真を撮るだけでハラルフードを見分けられるアプリなど、いろいろなものがでてきてとても良さがあった。

8月

  • 家族で箱根に旅行に行った。小田急箱根ハイランドホテルといういい感じのところだった。コースのディナーを食べたり、ピーター・ティールのZERO TO ONEを読み終えたりした。 www.hakone-highlandhotel.jp

  • IndiegogoでGPD Pocketを買った。結局大学で卒論を書くのに大活躍してくれた。 izumisy-tech.hatenablog.com

9月

  • Meguro.rbでROM.rbについてLT発表をした。初めてで緊張したけど、とてもエキサイティングでいい経験になった。

  • ダンケルクを見た。戦争色が上手く再現されすぎていて本当に戦争イヤだなと思った。死にたくない。ダンケルクに始まった話ではないが、20歳を過ぎたあたりから戦争映画を見ると涙が出てしまうことが多くなった。 wwws.warnerbros.co.jp

10月

  • 右下の親知らずを抜いた。1時間超のドリル採掘作業はほんとにつらかった。抜歯後の痛みはどちらかといえば中が痛むとかそういうのではなく、縫合の糸で歯茎が引っ張られて痛いというのが大部分で、それだけで食事のモチベーションを無くした。ウィダーインゼリーを大量購入していたが、ゼリーを吸う動きも口の中の筋肉を使うからか奥歯の部分の歯茎が疼いてキツかった。

  • 9月末のMeguro.rbを筆頭に、思い立って4回のLT発表をした。 izumisy-tech.hatenablog.com

  • 楽天テクノロジーカンファレンスというデカイLT大会もあったが、ネタが出てこず参加しなかったのは後悔している。

  • Jelly Proという小さいスマホを買った。LINE MOBILEで運用している。 izumisy-tech.hatenablog.com

11月

  • 10月末頃から急にまたStackoverflowの意欲が再燃し、323だったのを551くらいまで上げる。

  • 卒論の提出が12月に控えているというのもあり、6月からやっていた内定バイトを年末までストップすることにする。教授も自分も焦りがでてくる。このあたりから毎日卒論のことが頭の片隅にあってすごくフラストレーションが溜まってくる。

  • 最後の卒論題目提出期間(うちの大学は2度に渡ってテーマを決めるタイミングがある)だったが、結局大したアイデアも出ず、行き当たりばったりなテーマで提出する。

  • 気分で髪を明るくし始めた。

12月

  • なぜか卒論で忙しかったのにStackoverflowで人助けに精をだしてしまう。そのおかげかスコアは順調に551から771まで伸びる。

  • 卒論の提出をした。結局最後の最後はギリギリまで教授にヘルプをしてもらいながらそれっぽいものが完成したので安心した。

  • 卒論提出の直後に今度は左下の親知らずを抜いた。今度は歯茎が引っ張られていたいとかそういうものはなかったが、今度は歯茎の腫れがずっと収まらず、これをかいているいまも奥にしこりがあるような感じがして違和感がある。右の奥歯はほとんど全快したが、歯茎が完成していないせいで食べ物が挟まったりして困っている。早く治らんかな。

  • Slip.itというソーシャル機能の一切ないブックマーキングアプリを作ったので、公開した。 slipit.me

まとめ

なんかまとまりのない一年でしたね。

グアム行ったのが今年だということを完全に忘れてました。来年もスノボ行きたい。

入門ROM.rb 第3回: Repository

さーて、お待ちかねのROM.rb入門の第3回はRepositoryから。

前回の記事はRelationを説明していますので、読んでない人は参考までに。 izumisy-tech.hatenablog.com

Repository

リポジトリと聞くと文脈的にPoEAAやDDDっぽい雰囲気を感じる人が多いのではないかと思う。

どちらも、最も重要な部分はレイヤード・アーキテクチャの考え方で責務を分離することなのではないかと思うが*1、ROM.rbのリポジトリも、公式のコア・コンセプトの説明*2によるとレイヤード・アーキテクチャの考え方と近く、ドメイン・ロジックとデータアクセス・レイヤを粗結合なものにするためのboundary(境界)としての役割を担っている。

An important function of repositories is to act as a boundary between the data access logic and Application Domain logic. This boundary helps to reduce the complexity of rehydrating your entities and keeps a direct dependency on a particular datastore out of your domain.

リポジトリの重要な点は、ドメイン・レイヤからデータアクセス・レイヤの直接的な依存を追い出す(keeps a direct dependency on a particular datastore out of your domain)というところだ。

このコンセプトと対象的なアプローチはActiveRecordパターンだ。ActiveRecordパターンはあえてドメイン・モデルをデータアクセス・レイヤのデータ構造を粗結合にすることによって、インピーダンス・ミスマッチ*3を減らし、高速なアプリケーション開発を可能にしている。

だが一方で、ActiveRecordパターンでは一挙に「モデル」と呼ばれる責務がデータアクセス・レイヤとドメイン・モデルを兼ねてしまうため、どうしてもモデルが肥大化し見通しが悪くなってしまう場合が多い。この点、ROM.rbではActiveRecordと異なり、データアクセス・レイヤとドメイン・レイヤの間にboundary(境界)としてリポジトリを挟み、それぞれの責務を異なるものとして粗結合な設計を出来るようにしようとしている。

Relationとの違い

前回の記事で説明したRelationは、Repositoryがドメインレイヤに近い存在であるのに対して、どちらかといえばインフラストラクチャ・レイヤに近い存在だ。

Relations ... provide APIs for reading the data from various databases, and low-level interfaces for making changes in the databases. Relations are adapter-specific, which means that each adapter provides its own relation specialization, exposing interfaces that make it easy to leverage the features of your database.

つまり、RelationがHTTPやSQLなどのような、アプリケーション本体の外側にあるアダプタ固有(adapter-specific)の操作をAPIとして提供するのに対して、RepositoryはそれらのRelationを更にドメイン・レイヤにふさわしい形でラップし、ドメイン・モデルがRelation(アダプタ)の操作から影響を受けないようにするためのレイヤであるということだ。

それでは実際に使ってみよう。

require "rom"
require "rom/sql"


#
# ## Relationを定義
#
# ROMのRelationは`ROM::Relation[:アダプタ名]`を継承したクラスとして定義する
# associationsブロックの中で`belongs_to`や`has_many`などの関連も定義をする
# ここで定義したRelationは下で出てくるROMの初期化の際にROMへの登録を行う必要がある。
#

module Relations
  class Users < ROM::Relation[:sql]
    schema(:users) do

      # Relationの関連定義はActiveRecordと似ている。
      # has_many, belongs_toやhas_many-throughなどがあるのでドキュメントを参照のこと
      # http://rom-rb.org/learn/sql/associations/

      associations do
        has_many :books
      end

      # schemaブロックの中では関連の定義に加えて以下のように明示的に
      # Relationのカラムを定義できる。この場合、プライマリ・キーは
      # `Types::Serial`である必要がある

      attribute :id, Types::Serial
      attribute :name, Types::String
      attribute :age, Types::Int
    end

    # Repositoryの中で呼び出せるクラスメソッドを以下のように定義できる
    # ROM.rbのSQLアダプタ(rom-sql)は内部でSequalizeを使っているので
    # where句などもその記法に従う

    def by_pk(id)
      where(id: id)
    end

    def adult
      where{age > 20}
    end
  end

  class Books < ROM::Relation[:sql]
    schema(:books) do
      associations do
        belongs_to :user
      end

      # booksの場合にはuserに対してbelongs_toで関連を持っているので
      # その関連に対して`Types::ForeignKey(:users)`のように明示的に
      # 利用する外部キーを指定できる。ない場合には自動で推論される。

      attribute :id, Types::Serial
      attribute :title, Types::Int
      attribute :user_id, Types::ForeignKey(:users)
    end
  end
end


#
# ## Repositoryを定義
#
# Repositoryからは定義されているRelationを触ることができる
#

module Repositories
  class User < ROM::Repository[:users]
    # ROM.rbではRepositoryがRelationに対してどのようなアクセスをできるのか
    # という点を明確に制限できる。ここでは:createをコマンドとして有効化しているが
    # :create以外にも:updateや:deleteがある。
    commands :create

    # 以下のようにクラスメソッドを定義できる。
    # これらのデータはROM::Structによってラップされて返される
    # ここではusersのみを読んでいるが、booksも同様にメソッドのなかでアクセスできる

    def adults
      users.adult
    end

    # `aggregate`メソッドを使うことによって、Relationで定義されている
    # 関連Relationのデータを子要素としてフェッチできる
    # `aggregates`を呼ぶ場合には明示的にRelationを指定しなくてもよさそう。

    def all
      aggregate(:books)
    end

    def by_id(id)
      aggregate(:books).by_pk(id).one
    end
  end
end


#
# ## ROMにRelationを登録
#
# 上で定義した2つのRelationをROMに登録
#

config = ROM::Configuration.new(:sql, "sqlite::memory")
config.register_relation(Relations::Users)
config.register_relation(Relations::Books)
rom = ROM.container(config)

# SQLiteでテーブルを作るマイグレーションを適用

migration = ROM::SQL.migration(rom) do
  change do
    create_table(:users) do
      primary_key :id
      string :name
      integer :age
    end

    create_table(:books) do
      primary_key :id
      foreign_key :user_id, :users
      string :title
    end
  end
end

gateway = rom.gateways[:default]
migration.apply(gateway.connection, :up)


#
# ## Repositoryを使ってみる
#
# RepositoryはRelationとは異なり、ROMへ登録するのではなく、ROMのインスタンスを
# コンストラクタDIすることでRepositoryのインスタンスを作るという形になる。
#

userRepository = Repositories::User.new(rom)
userRepository.create(name: "Justine", age: 10)
userRepository.create(name: "Jessy", age: 18)
userRepository.create(name: "Michael", age: 23)

# テストのためにBooksテーブルにRelation経由でデータを入れてみる
# (外部キー成約があるので、userレコードを作ったあとじゃないとダメ)

books = rom.relations[:books]
books.insert(title: "Good Book", user_id: 1)
books.insert(title: "Nice Book", user_id: 1)

#
# ### Repositoryからレコードを取得
#
# ここでは`by_id`や`adults`などの、Repositories::Userの中で定義した
# クラスメソッドを呼び出すことができる。Relationの結果が常にハッシュなのに対して
# Repositoryによる取得の返り値はROM::Structという構造体の形になる。
# これはデフォルトでtrueになっている`auto_struct`をfalseに指定することで
# 止めることができる
#

users = userRepository.all
users.each { |user| p user }
# => #<ROM::Struct::User id=1 name="Justine" age=10 books=[
#       #<ROM::Struct::Book id=1 title="Good Book" user_id=1>,
#       #<ROM::Struct::Book id=2 title="Nice Book" user_id=1>
#     ]>
#    #<ROM::Struct::User id=2 name="Jessy" age=18 books=[]>
#    #<ROM::Struct::User id=3 name="Michael" age=23 books=[]>

single_user = userRepository.by_id(1)
p single_user
# => #<ROM::Struct::User id=1 name="Justine" age=10 books=[
#       #<ROM::Struct::Book id=1 title="Good Book" user_id=1>, 
#       #<ROM::Struct::Book id=2 title="Nice Book" user_id=1>
#     ]>

users = userRepository.adults
users.each { |user| p user }
# => #<ROM::Struct::User id=3 name="Michael" age=23>

このように、RepositoryはRelationをドメインモデル(ROM::Struct)へと変換するインターフェイスの役割を果たしていることが分かる。

加えて、たとえばRepositoryが返すドメインモデルのインスタンスを独自のクラス定義にマッピングしたくなるかもしれない。その場合にはauto_structをtrueに維持したうえで、ROM::Structを継承した独自のクラスにRepositoryの中でマッピングするよう指定できる。そのやり方に関しては、次回以降説明していこうと思う。

*1:DDDとレイヤードアーキテクチャはイコールではないが、便宜的に。

*2:http://rom-rb.org/4.0/learn/getting-started/core-concepts/#repositories

*3:簡単に言うと、永続化レイヤ(たとえばデータベース)のデータ構造と永続化対象(たとえばドメインモデル)のデータ構造の整合性の差異

入門ROM.rb 第2回: Relation

さて、入門ROM.rbの第2回は、まずRelationから。

ROM.rbとはなんぞやという方は第1回の下の記事からどうぞ。 izumisy-tech.hatenablog.com

入門なのでいきなりSinatraRailsとどう使うか、ではなくワンソースでどういうAPIがあって、どう使うのか、というところから見ていこうと思う。ちなみに、ソースコードにコメントを書いて読み進めながら学んでいけるスタイルをConversational Tutorial*1というらしい。

Relation

ROMにおけるRelationはインフラレイヤの一部で、アダプタ(Gateway)の実装を隠蔽するインターフェースのような役割を果たす。Relationの中では、そのRelationが対象とするアダプタの操作が行える。

それでは実際に使ってみる

require "rom"
require "rom/sql"

#
# ## Relation
#
# RelationはROM.rbにおいてアダプタ固有の操作をラップする永続化レイヤの責務を扱う
# SQLiteやMySQL固有の操作はAdapterに実装されており、それらに対するインターフェースを提供する
# (余談ではあるが、rom-sqlは中のSQLビルダにSequelを使っている)

module Relations
  class Users < ROM::Relation[:sql]

    # schemaをROM::Relationの継承クラスの中で使うことでデータベースのスキーマを定義できる
    # MySQLなどのデータベースを使っていれば、`schema(infer: true)`の一文でスキーマ推論を有効化できる

    schema(:users) do
      attribute :id, Types::Int
      attribute :name, Types::String
      attribute :age, Types::Int
      attribute :has_car, Types::Bool
    end

    # インスタンスメソッドを定義することで、Relationが持つメソッドを追加できる
    # ここでは、Relationが対象としているアダプタ(例えばこのコードの場合はSQLite)
    # に定義された固有の操作が行える。whereはSQLiteアダプタの中で定義されている。

    def all
      where()
    end

    def has_car
      where(has_car: true)
    end

    # デフォルトではすべてのカラムが返り値のレコードに含まれて返されるが
    # それを変更したければdatasetを定義することができる。
    # この例の場合はhas_carを意図的にレコードに含めないようにしている。

    dataset do
      select(:id, :name, :age)
    end

  end
end

# ROMを初期化して定義したRelationを登録する。
# auto_registrationというディレクトリをまるごと登録対象にできるメソッドがあるので
# ちゃんとしたプロジェクトであればそちらをつかうのがよい。

config = ROM::Configuration.new(:sql, "sqlite::memory")
config.register_relation(Relations::Users)
rom = ROM.container(config)

# データベースのテーブルがないのでマイグレーションをする
# こちらもちゃんとしたRakeタスクをROMが用意してくれているので
# まともなプロジェクトではこのようにマイグレーションを書くことはない。

migration = ROM::SQL.migration(rom) do
  change do
    create_table(:users) do
      primary_key :id
      string :name
      integer :age
      boolean :has_car, default: false
    end
  end
end

gateway = rom.gateways[:default]
migration.apply(gateway.connection, :up)

# 
# ## ROMに登録されたRelationを操作してみる。
#
# Relationを経由すればinsertなどのSQLite固有のメソッドも使えるが、できればRelationのメソッド
# としてラップしたほうがよい。固有のメソッド以外にもoneやallなどのビルトインメソッドもある。
# RelationはROMによってシングルトンのオブジェクトにされるので、`rom.relations[:クラス名]`でアクセスできる。

users = rom.relations[:users]

users.insert(name: "Bob", age: 22, has_car: true)
users.insert(name: "Alice", age: 23)

p users.all.to_a # [{:id=>1, :name=>"Bob", :age=>22}, {:id=>2, :name=>"Alice", :age=>23}]

p users.has_car.to_a # [{:id=>1, :name=>"Bob", :age=>22}]

 上のコメントでも触れているように、RelationというのはAdapterのラッパなので、ROM::Relation継承クラスではできるだけアダプタだけが知っている操作を隠蔽するような実装にしていくのがよい。そうすることで、アプリケーションが外部のインフラレイヤと粗結合になり、変更に強くすることができる。

 たとえば、サンプルではinsertメソッドを直接Relationから読んでしまっているが、例えばHTTPアダプタなら必ずしもinsertではなくpostメソッドのようなものが生えているかもしれない。ROMを使うアプリケーションにとっては、インフラレイヤのアダプタがデータベースなのかWebAPIなのか、という点は興味の対象にはならないので、実際のアダプタの操作を抽象化して隠蔽するメソッドがRelationに生えているほうが好ましいと言える。

*1:たとえばROMの作者が書いているチュートリアルブログもこの形式になっている: https://www.icelab.com.au/notes/a-conversational-introduction-to-rom-rb