ドメインモデル貧血症について

オブジェクト指向の勉強をしていたら、「ドメインモデル貧血症」という聞き慣れない用語が出てきたので、ちょっと調べてみた。

これは、どういうクラス(モデル)かというと、フィールド変数とその getter や setter くらいしかメソッドを持たないもので、オブジェクト指向的には良くないとされる。

なぜ良くないかというと、オブジェクト指向的には、データ(フィールド変数)とそれについての操作(メソッド)は同じクラス内にあるべきであり、ドメインモデル貧血症はそうなっていないからである。

そうなっていないと、どういう実害があるかというと、例えば、そのクラスのデータを加工する必要がある場合、クラスを使う側のソース(クライアント側)に加工処理を書く必要があり、その箇所がたくさんあると同じような処理がいろんな箇所に書かれることになってしまう。

ちなみに、上述ようなクラスが必ずダメかというと、そういうわけではなく、例えば DTO (Data Transfer Object) などのように、データを格納することだけを目的としたオブジェクトの場合は問題ない。

オブジェクト指向プログラミングをしていて、どのクラスに処理(メソッド)を持たせるのか迷ったら、この考えを思い出してみたいと思う。

以下も参考にさせて頂きました。

ドメインモデル貧血症

ドメインモデル貧血症 | システム設計日記

SSL/TLS 署名アルゴリズム

先日、SSL/TLS の署名アルゴリズム(ハッシュアルゴリズム)について話が挙がった時、「あれ？署名アルゴリズムって SSL/TLS通信のどこで使用されるんだっけ・・？」となってしまったので、また忘れないようにここに簡単に纏めておく。

署名アルゴリズムは、SHA-1/2やDES などがあり、クライアントがサーバからサーバ証明書を受け取った時にそれが信頼できるものかどうかを確認するために使用される。つまり、SSL/TLS通信の前段階の証明書チェックで使用される。

この辺のメカニズムについてより詳しく説明すると、クライアントがサーバからサーバ証明書を受け取った時に、サーバ証明書にハッシュアルゴリズムを適用し、メッセージダイジェスト(Aとする)を生成する。また、証明書についている電子署名から(CAの公開鍵を使って)メッセージダイジェスト(Bとする)を復元し、AとBが一致するか確認して、一致すればその証明書は信頼できるものとする。

以下も参考にさせて頂きました。

誰でもわかる SSL (HTTPS) 通信の仕組み [図解]

SSL証明書の署名アルゴリズムとは？

perl でハッシュを使って探索を高速化する。

要素数が大量にある配列に対して線形探索を行うと、とても時間がかかることがある。その場合、各要素をハッシュの key に入れておくと、探索の際にかなり高速化できる。以下のコードでは、配列をgrepする場合、配列をforeachで回す場合、(今回取り上げている)ハッシュから検索する場合にかかる時間を計測している。
ちなみに、今回の場合、ハッシュの value は何でも良いので、適当に 0 を入れている。(★の箇所)

use strict;
use warnings;
use Time::HiRes "gettimeofday";

# Searching 10000000 from 1~10000000. It's the worst case for linear search.
my $minNum = 1;
my $maxNum = 10000000;
my $numToBeFound = $maxNum;

# Setting numbers to an array and a hash.
my @numArray;
foreach my $num ($minNum .. $maxNum) {
    push(@numArray, $num);
}
my %numHash;
foreach my $num (@numArray) {
    $numHash{$num} = 0; # ★
}

# Case 1.
# Grep the array.
my $startTime = getCurrentTime();
if (grep {$_ == $numToBeFound} @numArray) {
    print "Exist.\n";
}
my $endTime = getCurrentTime();
my $elapsedTime = $endTime - $startTime;
print "$elapsedTime about grepping the array.\n";

# Case 2.
# Foreach the array.
$startTime = getCurrentTime();
foreach my $num (@numArray) {
    if ($num == $numToBeFound) {
        print "Exist.\n";
        last;
    }
}
$endTime = getCurrentTime();
$elapsedTime = $endTime - $startTime;
print "$elapsedTime about foreach the array.\n";

# Case 3.
# Search the hash.
$startTime = getCurrentTime();
if (exists($numHash{$numToBeFound})) {
    print "Exist.\n";
}
$endTime = getCurrentTime();
$elapsedTime = $endTime - $startTime;
print "$elapsedTime about searching the hash.\n";


sub getCurrentTime {
    my ($epochSec, $microSec) = gettimeofday();
    return $epochSec + $microSec/1000000;
}

これを実行すると、以下のようになる。

0.305840015411377 about grepping the array.
0.317622900009155 about foreach the array.
0.000194072723388672 about searching the hash.

配列に対して grep した場合と foreach で回した場合にかかる時間はだいたい同じ(約0.3秒)。一方で、ハッシュに対して探索を行った時は圧倒的にかかる時間が少ない(約0.0002秒)。たぶん、ハッシュを使った場合、perl が内部で効果的な探索を行ってくれるのだろう。

SNMP Report PDU が使われる場面

先日、SNMP report - ITエンジニアの技術メモ にて、「SNMP Report はあまり見たことがない」と書いたが、最近、SNMP Report が使われる場面を見つけたのでメモしておく。

https://www.ietf.org/rfc/rfc2574.txt に以下の記載がある。

4. Discovery

The User-based Security Model requires that a discovery process
obtains sufficient information about other SNMP engines in order to
communicate with them. Discovery requires an non-authoritative SNMP
engine to learn the authoritative SNMP engine's snmpEngineID value
before communication may proceed. This may be accomplished by
generating a Request message with a securityLevel of noAuthNoPriv, a
msgUserName of zero-length, a msgAuthoritativeEngineID value of zero
length, and the varBindList left empty. The response to this message
will be a Report message containing the snmpEngineID of the
authoritative SNMP engine as the value of the
msgAuthoritativeEngineID field within the msgSecurityParameters
field. It contains a Report PDU with the usmStatsUnknownEngineIDs
counter in the varBindList.

・・・

これによると、SNMPマネージャが (SNMPv3)エージェントに空のリクエストを投げる。それに対して、エージェントが SNMP Report に自分のエンジンIDを含めて応答する。これでSNMPマネージャはエージェントのエンジンIDを知ることができ、SNMPv3通信を開始すると読める。

つまり、SNMP Report は、SNMPマネージャがSNMPv3エージェントと通信するために、そのエンジンIDを知る目的で使用されることがあるということ。

ちなみに、https://tools.ietf.org/html/rfc3414

にも同様の説明がある。

以下も参考にさせて頂きました。

SNMP v3 の engineID とかのメモ - ngyukiの日記

2038年問題への対応

C言語で作成されたアプリの2038年問題への対応について調べてみた。なお、2038年問題については以下を参照。

2038年問題 - Wikipedia

2038年問題で主に問題として挙げられるのは、時刻データを格納する time_t 型が符号付き 32bit なので、その最大値は (2^31 − 1) = 2,147,483,647 となり、扱える年数が 2,147,483,647秒 (≒ 68年) までに限られてしまうことである。

 上述の time_t 型は、time.h にて long 型として定義(typedef)されており、long 型は limits.h でその最大値が定義されている。long 型の最大値は処理系 (コンパイラ) によって変わり、32bit 環境のものでは (2^31 − 1) = 2,147,483,647 となり、64bit 環境のものでは (2^63 - 1) = 9,223,372,036,854,775,807 となることが多いようだ。time_t 型が (2^63 - 1) まであれば、西暦3000億年くらいまで使用できるので、もうｘｘｘｘ年問題とか気にしなくて良いレベルである。

つまり、long 型が 64bit で定義されている環境 (処理系) でアプリをコンパイルすれば、time_t 型で扱える年数が格段に増えて、2038年問題を回避できるはず。最近の環境ではそうなっていることが多いと思うので、新しめの環境でアプリをコンパイルすれば、だいたい2038年問題対策は出来ていることになるのだろう。

# 時刻を表すのに time_t 型を使わず、int 型などを使っていたら、その部分の修正も必要になってくるが・・。

以下も参考にさせて頂きました。 

C言語と2038年問題 - エクセレンス★ブログ

シェルスクリプトで標準エラー出力を纏める

シェルスクリプトで標準エラー出力を一つのファイルに纏めたい場合、

  exec 2> 出力先ファイル

とシェルスクリプト内に記載する。こうすると、これ以降の標準エラー出力が「出力先ファイル」に吐かれる。これをシェルスクリプトの冒頭付近に書いておけば、シェルスクリプト内でコマンドを実行するたびに、

  command 2> 出力先ファイル

とかやらなくて済むので楽。

プロフィールムービーの作成方法

フリーソフトなどを使い、結婚式で使用するプロフィールムービーをほぼ無料で作成した。その方法について書く。

ちなみに、持っているPCはWindows10。作成したプロフィールムービーは 家庭用のDVDプレーヤーで再生される前提。

1. パワーポイントで内容を作成。「画面の切り替え」⇒「自動的に切り替え」で、一定時間でスライドが切り替わるようにしておく。また、必要に応じてアニメーションを入れる。
2. パワーポイントを保存する時に動画形式 (mp4) を選択して保存する。
3. 作成したmp4動画をオーサリングソフトを使って DVDビデオ形式に変換する。今回はオーサリングソフトとして DVD Flick (http://www.dvdflick.net/) を使用した。
4. 作成したDVDビデオデータをDVDに焼く。DVDに焼く際、ファイナライズしないと読み込めないDVDプレーヤーがあるらしいので、ファイナライズできる焼きソフトを使った方が良い。今回は ImgBurn (http://www.imgburn.com/) を使用した。

この方法なら、DVD-R(W)を購入する以外の費用はかからずに済む。冒頭で「"ほぼ"無料」 と書いたのは、DVD-R(W)を購入する費用があるため。なお、パワーポイントを持っていない場合もあると思うが、(パワーポイントを含む) Microsoft Office は一か月無料の体験版が使える。

Microsoft 公式 – 家庭向け Office の無料試用版ダウンロード

[補足]

上記手順は、ある程度 ITリテラシーがないと難しいかもしれないので、よく分からなかったり、時間のない人は式場側に頼んでしまった方が良いかも。（その分のお金はかかると思うが・・）