2018-08-17

依存関係について再び考える

プログラミングメモ

izumisy-tech.hatenablog.com

あとからこの過去記事を読み返して「ムム」と思うところがあったので改めて。
CategoryId ではなく Category を引数として渡すことでデータ構造が隠蔽されているという旨の説明をしているが、これは fetchArtclesByCategory を呼び出す側の責務が「CategoryのデータとしてIDが取れる」という知識を持ってしまうのを防げるという意味で書いたのではないかと思う。
けれどもその実装だと、結局 fetchArticlesByCategory 関数側が、引数として受け取る Category からIDを取り出すという処理をせなばならず、ID呼び出しでないという設計指針が fetchArticlesByCategory に対して Category への依存を与えてしまっている。
この依存が別に構わないという可能性もあり、たとえば Category がドメインモデルなのであれば、そのドメインモデルに対して単方向の依存を持つクリーンアーキテクチャ的観点でいうところの外部のレイヤとして fetchArticlesByCategory が存在していると考えることもできるので、さほど問題を感じなくなる。
ところで fetchArticlesByCategory 関数を呼び出すのは、アプリケーションの責務のうち誰になるのだろうか... またまたクリーンアーキテクチャを考えてしまうが、おそらくユースケース層ではないかと思う。
DDD的観点: CategoryId を渡す場合においての別の懸念点としては、もしも CategoryId が Category という集約ルートにおける値オブジェクトだとしたら、それを CategoryId 単体で受け取ってしまえるインターフェースもった関数 fetchArticlesByCategoryId があることで、利用者によって不変条件を保たずにつくられたおかしな CategoryId が渡ってくる可能性があるのではないかということ。正直ここは実装の問題のような気もするけど...

Clean Architecture 達人に学ぶソフトウェアの構造と設計

作者: Robert C.Martin,角征典,高木正弘
出版社/メーカー: KADOKAWA
発売日: 2018/07/27
メディア: 単行本
この商品を含むブログを見る

2018-08-05

クラウドバンクをやっている

雑記

OneTapBUYをやっていたときもこういう記事を書いていたので今回はクラウドバンクについて書く

izumisy-tech.hatenablog.com

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

ちょうどこの記事を書いた2017年の10月から始めていた。結論からいうと、自分のクラウドバンクのパフォーマンスは年利で3.8%という感じになっている。

f:id:IzumiSy:20180805121827p:plain

今現在で80万程度つっこんでいるわけだが、それで増えたのが1.8万くらい。こう見るとOneTapBUYにもっとお金を突っ込んでいたほうが今頃には利益がもっと出ていたかもしれない。

2017年の10月の記事ではOneTapBUYでは12万で1万の利益がでている！みたいに書いたが、その翌月には5000近くまで下がってしまっていた。もちろん株なんてものはそうやって上がったり下がったりするものではあるが「こういうの、いつも気になってしまってソワソワしてしまうな〜」という感覚を持った。その当時はまだ学生で毎月定期的な収入があるわけでもなかったため、いわゆるドルコスト平均法のような積立戦略を実践するにも難しさがあり、短期的な売買に終始していたからという理由もある。

その点クラウドバンクはある意味ただの投資に近いので、自分の利益が上がったり下がったりするのを見る必要はないし、そもそも見えない。預けたものに毎月分配金がつくだけでシンプル。見方を変えれば、株と違って自分で取捨選択をしている感覚がないので、地味といえば地味ではある。とはいえ、社会人にもなるとそんなに毎日自分のポートフォリオの上がり下がりを見ている余裕はそんなにないので、どちらかといえば勝手に誰かがやっていてくれるほうがうれしいというものだ。そういう理由もあって2017年の11月にはOneTapBUYで投資していた分を5000円プラスで売却し、クラウドバンクに突っ込むことにしたのだ。

f:id:IzumiSy:20180805122942p:plain

ココ最近のペースでは毎月3000円くらいの分配金が入ってきている。毎月一回くらい飲み会にタダでいける程度ではあるが、それでもこうやってお金が増えていく様子をみるのはうれしいものがある。

2018-06-13

JavaScriptにおける配列操作の計算量オーダー

メモプログラミング JavaScript

日本語だとググっても出てこなかったのでまとめた

操作	計算量
添字アクセス	O(1)
挿入(splice)	O(n)
削除(splice)	O(n)
削除(delete)	O(1)
最後に追加	O(1)
先頭に追加	O(n)
スワップ	O(1)

添字アクセスがO(1)だったりするのは、JavaScriptの配列は連結リストなどではなく単なるインデクスをキーで持つObjectだから。

ちなみにdeleteを使った削除というのはspliceと違って要素がundefinedと交換されるだけのものなので後続要素への走査が走らないためO(1)になる。

参考: https://stackoverflow.com/questions/11514308/big-o-of-javascript-arrays

2018-06-11

結果整合性について

メモ

歴史

かつて、分散システムのデータ複製における唯一無二の理想は「更新されたデータは即座に反映される」というものだった。
70年台の分散システム技術において試みられているものの多くは、いくら背後にたくさんのシステムが控えているとしても「使う人間からはひとつのシステムを使っている」ように見せることで、その観点から主に議論されていたものの多くはデータの一貫性（Consistency）をいかにして獲得するかという部分に主眼が置かれたものだった。
90年台中頃からインターネット・システムの規模が大型化してくると、開発者の多くはデータの一貫性を犠牲にしてもスケーラビリティを担保することが重要なのではないかと考えはじめた。
AWSは世界規模で利用されるシステムを開発するにあたってあらゆる場所でレプリケーション技術を活用してきたが、その中で結果整合性モデルはレプリケーションにおいてデータの一貫性を担保するための技術として提供されてきた。
AmazonのCTOであるWerner Vogelsは「並行処理における書き込み・読み込みパフォーマンスの担保」と「データロックによるノードの可用性の低下の抑止」の２つの観点から、データの一貫性はスケーラブルな大規模システムにおいてはさほど重視される必要はないと考えている。

強整合性と結果整合性の違い

	強整合性	結果整合性
データのロック	あり	なし
スケーラビリティ	低い	高い
一貫性	担保される	すぐには担保されない

強整合性 の場合、データの更新の際にデータベースをロックすることによってデータの一貫性（Consistency）を担保するが、ロックされる期間が長いほどその間のデータベース・アクセスがブロックされ、可用性（Availability）を犠牲にすることになる。
結果整合性 はデータの更新でデータベースがロックされることはないため、可用性とスケーラビリティを維持することができる。その代わりノード間でのデータの一貫性はデータ複製にかかる時間に依存することになるため、必ずしも担保されない。

その他

結果整合性は必ずしも高度な分散システム固有の難解な技術ではなく、多くのモダンなRDBMSは同期・非同期レプリケーションのシステムが組み込まれている。同期的レプリケーションの場合にはレプリケーションの更新はトランザクションの一部として行われるが、非同期的レプリケーションでトランザクションログの伝播の前にプライマリーでのデータ更新が失敗すると、ノード間で一貫性のないデータが生まれることになる。つまり非同期レプリケーションはRDBMSにおける古典的な結果整合性のケースのひとつである。

参考

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

作者: Martin Kleppmann,斉藤太郎,玉川竜司
出版社/メーカー: オライリージャパン
発売日: 2019/07/18
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2018-06-10

AnyValを継承する意味

Scala プログラミングメモ

ScalaでDDDなコードのアプリケーションを作ろうとしているときに UserId など値型はどうするべきかの記事を読み、「専用の値クラスを作る」のパターンでふと 「ここでケースクラスが AnyVal を継承する理由ってなんだ...？」 と思ったので調べた。

case class PersonId(value: Long) extends AnyVal
case class PersonName(value: String) extends AnyVal
case class OrganizationId(value: Long) extends AnyVal

case class Person(id: PersonId, name: PersonName, organizationId: OrganizationId)
// ...

AnyValを継承すると

AnyValを継承すると値オブジェクトになる。値オブジェクトを継承したクラスはひとつの値しかとれない。

// OK
class Melo(val a: Int) extends AnyVal

// NG
class Melo(val a: Int, val n: String) extends AnyVal

AnyVal を使うことによって 実行時のオブジェクト割り当てを回避することができる ようになる。具体的には上の例でいうと Melo クラスはコンパイル時は Melo クラスだが、実行時は Int として解釈される（アンボクシング）

だが、パターンマッチングなどで型検査が必要になると、 Int としてアンボクシングされた値が再び Melo としてボクシングされることになるため、パフォーマンスに影響を与える。

結論

雑に言うと AnyValを継承したクラスを使うとパフォーマンスが向上する っぽい。

個人的にはDDDにおける値オブジェクトをコードで表現するにあたって、もし 引数がひとつしかない のであれば、どんなケースでも AnyVal を継承しない理由がないように思える... というか、調べていて値クラスという名前がたまたまDDDっぽいだけであって、これならべつにエンティティの実装だって可能なら AnyVal 継承クラスでえんちゃうの、と思ってしまった。

ただ、例えばバリデーションロジックで 「〜文字以下かどうかをチェックする」 みたいなビジネスルールがあったとき、クラスの中に MAXIMUM_LENGTH みたいな定数を宣言するのは普通だが AnyVal を継承しているクラスの中で val による宣言ができないという制約がある。

コレに関しては、以下のようなメソッドを定義してしまえばいいのでは、という同期からのアイデアをもらったが、果たしてアリなのか...?

class Text(value: String) extends AnyVal {
  def MAXIMUM_LENGTH = 100
}

参考文献

値クラスと汎用トレイト | Scala Documentation

2018-04-24

Rubyにおけるポリモーフィズムとダック・タイピング

Ruby プログラミングメモ

自分がOOPをそれっぽく学んだのは、サンディ・メッツの「オブジェクト指向設計実践ガイド」だが、この本だとダック・タイピングはバキバキにでてくる一方であまりポリモーフィズムについては詳しく書かれていない。thoughtbotのブログの記事、Rubyとポリモーフィズムによると、Rubyにおけるポリモーフィズムは「継承」と「ダック・タイピング」によって実装できるらしい。

オブジェクト指向設計実践ガイド ~Rubyでわかる進化しつづける柔軟なアプリケーションの育て方

作者: Sandi Metz,?山泰基
出版社/メーカー: 技術評論社
発売日: 2016/09/02
メディア: 大型本
この商品を含むブログ (6件) を見る

継承

まずは継承のパターン。GenericParserというクラスを継承したis-a関係のJsonParserとXmlParserを定義し、parseメソッドをオーバーライドしている。

class GenericParser
  def parse
    raise NotImplementedError, 'Implementation required.' 
  end
end

class JsonParser < GenericParser
  def parse
    # Jsonをパースする実装 
  end
end

class XmlParser < GenericParse
  def parse
    # XMLをパースする実装 
  end
end

parser = XmlParser.new
parser.parse

parser = JsonParser.new
parser.parse

ダック・タイピング

つぎにダック・タイピング。ダック・タイピングでは、各パーサ実装はなんのクラスも継承せず、とにかくparseというメソッドを持っているということだけが共通している。

class XmlParser
  def parse
    # Jsonをパースする実装 
  end
end

class JsonParser
  def parse
    # XMLをパースする実装 
  end
end

class GenericParser
  def parse(parser)
    parser.parse
  end
end

parser = GenericParser.new
parser.parse(XmlParser.new)
parser.parse(JsonParser.new)

実装の違い

継承のコードでは、パーサを使う部分でそれが XmlParser なのか JsonParser なのかが意識されてparseメソッドが呼び出されている。
ダック・タイピング のコードでは、parseメソッドを呼び出すGenericParserは、そのメソッドを持つparserが何かを意識していない。

ということが分かる。

継承によるコードは、それぞれのパーサが「誰なのか」（＝なにを継承しているか）が分かることによって、パーサに何ができるか（どんなインターフェースを持っているか）を判断できる。一方で、ダック・タイピングとはすなわち「誰か」ではなく「何をするか」によってオブジェクトを見分けるため、パーサがparseメソッドを呼び出せるということを期待するだけでインターフェースは意識しない。

ダック・タイピングとポリモーフィズムの関係

「なるほど、ということはダック・タイピングはポリモーフィズムのサブセットなのだろうか？」 という疑問が湧いてくる。

これまで自分は、ポリモーフィズムとはis-a関係にある継承クラスが抽象クラスと共通したインターフェースで個々の振る舞いを特化したものに変えること、というような理解をしていた。なので、必ずしも共通したインターフェースが保証される関係ではないダック・タイピングはポリモーフィズムに該当しないと考えていたわけだ。だがWikipediaのポリモーフィズムのページによると、ダック・タイピングは動的ポリモーフィズム（英: Runtime Polymorphism）というものに該当するようだ。この意味では、ダック・タイピングは継承に並んでポリモーフィズムを実現するための手段であると言っても良いのではないかと思う。

とはいえ、Googleでポリモーフィズムとダック・タイピングについて調べるとStackoverflowの質問がそこそこヒットするが、回答者によってポリモーフィズムとダック・タイピングの関係をどう捉えるかというのは割れているように見える。ある人は 「ダック・タイピングはポリモーフィズムするための方法の一つで間違いないよ」 と言ったり、またある人は 「ポリモーフィズムはインターフェースによる明示性(explicitness)を必要をするものだからダック・タイピングは違う」 と言ったりしている。やはり、これに関してはもう少しOOPの原典的なものにあたったほうがいいのかもしれない。

2018-04-05

雑なDNSの理解

メモ雑記

Domain Name Systemの略
インターネットに接続されているすべてのコンピューターはIPアドレスを割り振られているが、数字でサイトを記憶しておくのは難しいので、DNSで覚えやすい文字列への解決を行う。
ARPANET時代はひとつのHOSTS.TXTにすべて書き込まれたものをFTPで共有していたが、ファイルがでかくなりすぎたのでDNS鯖が生まれた。
UNIX系OSにある /etc/hosts もDNSと同じ役割を持っている。
- これはARPANET時代のHOSTS.TXTの名残で、ローカルだけでDNSに問い合わせないドメイン名解決を行いたいときにはここに書いておく。
- 開発で localhost:3000 とかを hoge.net とかにしておくと楽になったりする（？）
- localhost が 127.0.0.1 に解決されているのはこのファイルによって。

名前解決

たとえばPCのブラウザで hogehoge.net へリクエストを送るまでの例

[PC] ブラウザで　hogehoge.net を開く。
[PC] /etc/hosts に該当するIPアドレスとの組み合わせがあればそれで解決
[家庭用ルーター] プロバイダからDNSルートサーバのIPアドレスを受け取る
[家庭用ルーター] hogehoge.net をDNSルートサーバに問い合わせる。
[DNSルートサーバ] net DNSサーバが管理しているという旨を家庭用ルーターに伝える
[家庭用ルーター] net DNSサーバへ hogehoge.net を問い合わせる
[net DNSサーバ] hogehoge.net のドメインを解決し、IPアドレスである 123.45.6.78 を家庭用ルーターへ伝える。
[家庭用ルーター] PCへ 123.45.6.78 を伝える
[PC] ブラウザは 123.45.6.78 へリクエストを送ってデータを取得したりする。

参考: インターネット10分講座 DNS - JPNIC

2018-03-20

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

D言語プログラミング

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

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();
  }
}

Runner in the High

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