かぐや様は告らせたい 感想

ミラクルジャンプでの好評を受けヤングジャンプに移籍した漫画.
表紙買いしたけど中々面白かったので紹介.

生徒会副会長の四宮かぐやと,同じく会長の白銀御行.
両者は両想いにも関わらず,プライドが高すぎるせいで
お互いに「自分から告白する」ことが出来ずにいた.
膠着状態に業を煮やした両者は,その類まれなる頭脳を
「何としてでも相手に告白させる」
という残念な方向へと活用し始める.

やってること自体は,生徒会の活動だったりゲームだったりなんだけど,
相手に「好き」と言わせるためにあらゆる手段を使う二人は
見ていて面白く,そして飽きない.

設定の制約が結構大きいのでネタ切れが少々不安だけど,
今のところ書記の藤原という第三のキャラを
ジョーカーとして上手に使っている感じ.

現時点で全5巻とお手頃なので,
こういうシチュエーションギャグが好きな人には
是非ともオススメ.

パトリオット・デイ(Patriots Day) 感想


『パトリオット・デイ』60秒予告
2013年のボストンマラソンで起きたテロ事件を元にした映画.
主要人物は実在の人物らしく,
映画の最後,本人達のインタビューが収録されていた.

まあ,典型的な「USA!USA!!」な映画.
題材的にある程度仕方ないとはいえ,
幾らなんでも犯人側を狂信者集団に仕立て上げすぎ.

あと,これは史実通りだから仕方ないんだけど,
警官数十人がかりで取り囲んだ状態から
たった1名の犯人を取り逃がすシーンには「えぇ……」となってしまった.
しかも,何かしらの策に嵌められたわけでもなく,
思いっきり正面突破されるという謎の展開.

たぶん,史実として別の理由で取り逃がしたところを
諸般の事情で,こういうストーリーに脚色したんじゃないかな.
全く根拠はないけど.

俺はこの事件の顛末についてはほとんど記憶していなかったので,
先が読めないという点では楽しめたんだけど,
普通に覚えていた人にとっては,特に面白みのない映画だったんじゃないかな.

正直,あんまオススメはできません.


ちなみにネット上ではこの事件について「やらせ」説があったりするけど,
そっちについては特にノーコメントとします.

Suits(スーツ) Season 1 感想

レンタルビデオ屋の近所に引っ越したので,
適当にチョイスして視聴.

主人公は,弁護士事務所のエースであるハーヴィー.
人を遠ざけがちな彼の性格を見かねた上司の命令により,
ハーヴィーは渋々,部下を1名雇うための面接試験を開始する.
面接会場に偶然逃げ込んできた青年マイクの才能に惚れ込んだハーヴィーは
マイクが弁護士の資格を持っていないという事実を隠した上で,
自分の部下として雇うことを決意する.

マイクは瞬間記憶という強力な能力を有しており,
それを活かして窮地を脱する場面もあるが,それ以上にポカが非常に多く,
正直,あまり有能なイメージは抱かない.
ハーヴィーの足を引っ張ってるシーンの方が多かったと思う.

この辺はシーズンを重ねるにつれて改善されていくらしいけど,
White Collarのニール的な役割を予想していた自分としては
マイクのキャラ付けには肩透かしを食らった.

そんなわけで,このシーズン1は
ハーヴィーの優秀さと,ライバル弁護士のルイスのウザさを
ひたすら堪能するシリーズだったと思う.

終わり方も海外ドラマお得意の続編ありきの尻切れエンドだったし,
これ1シリーズだけでは評価は難しいかな.


面白くなりそうだとは思うので次シリーズも見ると思うけど.

log4jを使う

仕事上は何度か使ったことあるけれど
自分で実装したことが無かったので,これを機会に勉強.

log4jというのは,java向けのlog管理ツールとでも呼ぶべきもの.
apacheから提供されている.
Log4j – Apache Log4j 2 - Apache Log4j 2
設定ファイルさえ用意しておけば,あとはシンプルなコマンドで
ログを出力することが可能となる.

仕組みは以下に整理されている.
Log4j – Log4j 2 Architecture - Apache Log4j 2
書いていることを要約すると,以下のような感じ.

・Loggerは名前を持ち,1つのLogConfigを持つ.
・LogConfigはログレベルを管理し,複数のAppenderを持つ.
・Appenderは出力先と出力フォーマット(Layout)を管理する.

また,LogConfigには継承関係も成り立つ.
「foo」の子供は「foo.bar」になる,といった具合だ.
で,継承の方法については以下になる.

・ログレベルの継承は「上書き」
・出力先(Appender)の継承は「追加」

たとえば,
foo:ログレベルはtrace,コンソール出力のAppenderを設定
foo.bar:ログレベルはerror,ファイル出力のAppenderを設定
と設定した場合,
foo.barは
「errorイベントのログを,コンソールとファイルの両方に出力する」
という振る舞いを見せる.

Appenderの継承方法も「上書き」にしたい場合,
additivityの設定をfalseにしておけば良いそうだ.
その辺は以下を見ると分かりやすい.
Log4j – Log4j 2 API - Apache Log4j 2


というわけで,御託はこれくらいにして,実装してみる.
今回は超シンプルに,以下.

package jp.nk5.stockanalyzer.controller;

import jp.nk5.stockanalyzer.application.DownloadStockDataService;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;

public class BatchController {

  private static final Logger logger = LogManager.getLogger();
	
  public static void main(String[] args) {
    logger.error("main() started.");
    DownloadStockDataService application = new DownloadStockDataService();
    application.downloadStockData();
    logger.error("main() finished.");
  }

}

ちなみに,設定ファイルはまだ用意していない.
「設定ファイルが無い場合,log4jはログレベル=errorでコンソール出力する」
という仕様があるため.上記は設定ファイル無しでも動くのだ.

実際の実行結果が,以下.

10:45:38.365 [main] ERROR jp.nk5.stockanalyzer.controller.BatchController - main() started.
10:45:40.257 [main] ERROR jp.nk5.stockanalyzer.controller.BatchController - main() finished.

さらに設定ファイルを以下の内容で用意してやれば,
app.logというファイルにログを出力してくれるようになる.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
  <Appenders>
    <File name="logFile" fileName="app.log">
      <PatternLayout>
        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
      </PatternLayout>
    </File>
  </Appenders>
  <Loggers>
    <Root level="error">
      <AppenderRef ref="logFile"/>
    </Root>
  </Loggers>
</Configuration>

設定ファイル(log4j2.xml)はクラスパス上であればどこに置いても良い.


というわけで,ロギング出来るようになったので,次回こそサーバ側を実装.

Eclipse+Git+Gradleな環境を作る

久しぶりにAndroidアプリ作ろうかなと思った.
今回やりたいのは以下のような感じ.

・サーバクライアントシステムにする.
・サーバ側で定期的に情報収集して,それをクライアントで参照.
・クライアントはもちろんAndroid

まずはサーバ側の開発環境を構築する.
IDEは手元にあったEclipseのバージョン4.4.0を使う.
いつダウンロードしたか覚えてない.

以下,やったこと.

(1)
Gitのリポジトリには,GitHubを使う.
アカウントは持っているので,そこに新たにリポジトリを作成.
何も入っていないが,当然最初はそれで良い.

(2)
前段で作ったリポジトリをcloneする.
コマンドラインでやっても良いと思うけど,Eclipseでやるなら,
「Window」の「Open Perspective」からGitのパースペクティブを開く.

3つくらいあるリンクのうちの「Clone a Git repository」を選択.
URLに,先ほどのリポジトリのURL(末尾が.gitのやつ)を入力して,
あとはよしなにウィザードを進めればcloneできる.

これは完全に気分の問題だけど,ローカルリポジトリのパスは,
普段Eclipseのworkspaceとして使っているディレクトリにした方が良いかな.

(3)
デフォルトだとGradleのプロジェクトを作ることはできないので,
まずは「Gradle IDE pack」をインストールする.

Eclipseの「Help」から「Eclipse Marketplace...」を選択する.
検索窓に「gradle ide」などと入力して,
「Gradle IDE Pack」をインストール.バージョンは「3.8.x+1.0.x」だそうだ.

作業中はスルーしてたけど,「Gradle IDEはもう古いよ」って警告が出るね.
後継は「Buildship」だそうです.そっちに差し替え.バージョンは2.0.

(4)
ローカルリポジトリにGradleプロジェクトを作る.
「File」の「New」からGradle(STS)プロジェクトを選択.
workspaceに,さきほどのローカルリポジトリを選択すれば良い.

BuildShipの場合は「Gradle Project」というのがあるのでそれを選ぶ.
あと,Buildshipだと同名フォルダがある場合,上書きしてくれないみたいなので
一旦別のフォルダにプロジェクトを作って,それらを一式
ローカルリポジトリに移動する,という作業が必要になる.

(5)
Gitのパースペクティブを開き,
masterブランチ上で右クリックコンテキストメニューの「Commit...」を選択.
適当なコメントを書き,全部選択して「Commit and Push」を選択.
認証を求められたら,GitHubのアカウント情報を入力すればOK.
あとは流れに従えば良い.

これでOK.
とりあえずこれで,Eclipse上でGradleプロジェクトを扱い,
それらをGitで構成管理……という構図を作成できた.
次からサーバ側の実装.

一切設計せずに見切り発車で進めるので,どっかでつまずく可能性99%.

2017年の広島東洋カープの展望

優勝の余波か,カープ戦のチケットがプレミア化していますね.
昨年も色々と話題&問題になりましたが,
今年は「広島ファンのマナー」が問われる1年になると思います.

じゃあ,展望予想.

■全体
4位と予想.
去年は出来すぎで,かつ「先発投手不足」という課題はそのまま.
いや,黒田の引退により,さらに状況は悪化したと言える.

一方,セリーグは他球団もイマイチ決め手に欠いているので,
ぶっちぎりで弱いとも言い切れないなと思っている.
なので,泥沼レースを勝ち抜いてくれることに期待して,4位.
シーズン中の補強が当たれば,もう1~2つは順位を上げられるかも.

ちなみに優勝は横浜と予想.
着実に戦力を築き上げている上に,ラミレスが監督として想像以上に優秀.
山口の穴埋めの可否という要素はあるが,十分首位を狙えると思う.

■先発
開幕時点で既に6人ローテの構築が絶望的な状態.
なし崩しで,九里をローテに組み込んでいるが,
おそらく5月には,いつものロングリリーフに落ち着いていると思う.

飛躍に期待する枠としては,戸田・薮田・塹江あたりだろうか.
ヘーゲンズに再び先発として頑張ってもらうことも選択肢に入れる必要があるかと.

■リリーフ
中崎・ジャクソン・今村の3枚が軸になるだろう.
昨年はさすがに出来過ぎだが,今年もそこそこやってくれると期待.
一昨年・去年と,運用面で失態を晒し続けた緒方監督&畝コーチだが,
そろそろ成長を見せてほしい.

■捕手
今年も石原を軸にする形にせざるを得ないと思う.
會澤と船越が,お互いに切磋琢磨しながら石原をサポートする形が理想かな.

■内野
新井をどれだけ上手に休ませられるかが重要になる.
交代要員が誰かというと,「こいつ!」とすぐに浮かばないが…….
セカンド菊池とショート田中は,仮に打てなくても基本的に固定だろう.
サードはペーニャかと思いきや,枠の都合で開幕2軍らしい.
安部の不調や西川の故障により,サードは1年通して頭を悩ませる形になりそう.

■外野
センター丸とライト鈴木は固定かな.
特に鈴木は,昨年の自分との闘いになると思う.辛いだろうが頑張って欲しい.
レフトは,おそらく開幕はエルドレッドだろうけど,
最終的に調子が良い選手を流動的に使っていくことになるかな.
本格コンバートの堂林は……とりあえず代打で信頼築くところからスタートか.


それでは,選手の皆さん,頑張ってください.

postfixの勉強 #5

以下の続き.
postfixの勉強 #1 - NK5のノート
postfixの勉強 #2 - NK5のノート
postfixの勉強 #3 - NK5のノート
postfixの勉強 #4 - NK5のノート

qmgr(8)の後に起動するプロセスが,
送信時は「smtp」だったのに受信時は「local」だった,という話.

この使い分けは,前回も触れたtrivial-rewrite(8)の挙動に起因する.
ここで仕様を再掲しておく.
Postfix manual - trivial-rewrite(8)

上記リンクにもあるとおり,trivial-rewrite(8)は,メールアドレスを元に
主にtransport(配達員)とnexthop(配送先)を解決する.
で,このtransportが,先述のsmtpだったりlocalだったりする.

解決ルールについては,以下の表がわかりやすいと思う.
http://www.kobitosan.net/postfix/jman/rewrite.html#transport

local(8)は,ローカルユーザ宛の配送エージェント.
設定については前回触れたとおり.
さらに,alias_mapsにaliases(5)の変換テーブルを設定していれば,
・taro@mydomain宛のメールを,jiro@mydomain宛に配送
・all@mydomain宛のメールを,taroとjiroの両ユーザ宛に配送
のようなことが可能になる.後者はメーリスのイメージかな.
詳しくは以下.
Postfix manual - local(8)

smtp(8)は,外部ユーザ宛の配送エージェント.
SMTP認証なんかも関わってくるけど,今回は深くは触れないので
リンクだけ貼ってお茶を濁しておく.
Postfix manual - smtp(8)

virtual(8)は,バーチャルユーザ宛の配送エージェント.
バーチャルユーザというのは,名前の通り,実在しないユーザ.
「いちいち受信ユーザ毎にアカウントなんか作ってられるかよ」
という人向け,になるのかな.
実際にやってみる.

# vi /etc/postfix/main.cf
(編集作業,中略)
# grep "virtual_mailbox_domains =" /etc/postfix/main.cf
virtual_mailbox_domains = oreore.com
# grep "virtual_mailbox_base =" /etc/postfix/main.cf
virtual_mailbox_base = /etc/postfix/base
# grep "virtual_mailbox_maps =" /etc/postfix/main.cf
virtual_mailbox_maps = hash:/etc/postfix/v_m_maps
# grep "virtual_gid_maps =" /etc/postfix/main.cf
virtual_gid_maps = static:1919
# grep "virtual_uid_maps =" /etc/postfix/main.cf
virtual_uid_maps = static:114514

設定の意味合いとしては,
・oreore.com宛のメールは,virtual(8)が配送します.
・配送先のルートディレクトリは,/etc/postfix/baseです.
・配送先はv_m_mapsに基づいて最終決定します.
・メールの保存で使うグループのgidは1919です.
・メールの保存で使うユーザのuidは114514です.
といった感じになる.

ちなみに,gid:1919も,uid:114514も,存在しないidとなる.
これでもまあ,動くことは動くんだけど(それを証明するために使った),
管理面で面倒になるので,本来は管理用のグループ&ユーザを用意した方が良い.

また,「static:xxx」の部分は,今までのように「hash:yyy」として
変換テーブルyyyを用意……という戦法でも良い.
こういう手段もあるよ,というのを紹介するために使った.

上記で設定した「/etc/postfix/base/」と「/etc/postfix/v_m_maps」は
当然まだ存在しないので,以下のように用意してあげる.

# mkdir -m o+w /etc/postfix/base

# vi /etc/postfix/v_m_maps
(作成作業,中略)
# cat /etc/postfix/v_m_maps
taro@oreore.com taro/
# postmap /etc/postfix/v_m_maps

# ll /etc/postfix
total 172
-rw-r--r-- 1 root root 20876 Jun 10  2014 access
drwxrwxrwx 2 root root     6 Mar 28 14:18 base
-rw-r--r-- 1 root root 11681 Jun 10  2014 canonical
-rw-r--r-- 1 root root  9904 Jun 10  2014 generic
-rw-r--r-- 1 root root 21545 Jun 10  2014 header_checks
-rw-r--r-- 1 root root 27480 Mar 28 13:59 main.cf
-rw-r--r-- 1 root root  6105 Jun 10  2014 master.cf
-rw-r--r-- 1 root root  6816 Jun 10  2014 relocated
-rw-r--r-- 1 root root 12549 Jun 10  2014 transport
-rw-r--r-- 1 root root    22 Mar 28 13:36 v_m_maps
-rw-r--r-- 1 root root 12288 Mar 28 13:36 v_m_maps.db
-rw-r--r-- 1 root root 12494 Jun 10  2014 virtual

baseディレクトリ作成時に権限を追加してるのは,
gid:1919およびuid:114514とかいう,実在しない適当なユーザでも
ファイルやディレクトリ作成を出来るようにするため.

メールの保存ディレクトリは
「(virtual_mailbox_baseの設定値)/(virtual_mailbox_mapsの変換結果)」
になるので,上記設定だと,taro@oreore.com宛のメールは
/etc/postfix/base/taro/
に保存されることになる.

最後に忘れずにリロード

# postfix reload
postfix/postfix-script: refreshing the Postfix mail system

これで,バーチャルユーザ「taro」にメールを届ける準備が整った.
(useraddもgroupaddも実施していない)
早速メールを送ってみる.以下は送信後の状況.

# journalctl -n 7
Mar 28 14:28:39 3832cc77bd2d postfix/smtpd[1032]: connect from (メールの送信元のホスト名)[172.17.0.1]
Mar 28 14:29:10 3832cc77bd2d postfix/smtpd[1032]: 73BDB60138FD: client=(メールの送信元のホスト名)[172.17.0.1]
Mar 28 14:29:54 3832cc77bd2d postfix/cleanup[1036]: 73BDB60138FD: message-id=<>
Mar 28 14:29:54 3832cc77bd2d postfix/qmgr[1028]: 73BDB60138FD: from=<■■■@gmail.com>, size=321, nrcpt=1 (queue active)
Mar 28 14:29:55 3832cc77bd2d postfix/virtual[1037]: 73BDB60138FD: to=<taro@oreore.com>, relay=virtual, delay=57, delays=57/0.07/0/0.03, dsn=2.0.0, status=sent (delivered to maildir)
Mar 28 14:29:55 3832cc77bd2d postfix/qmgr[1028]: 73BDB60138FD: removed
Mar 28 14:29:57 3832cc77bd2d postfix/smtpd[1032]: disconnect from (メールの送信元のホスト名)[172.17.0.1]

# ll /etc/postfix/base/taro/
total 0
drwx------ 2 114514 1919  6 Mar 28 14:29 cur
drwx------ 2 114514 1919 58 Mar 28 14:29 new
drwx------ 2 114514 1919  6 Mar 28 14:29 tmp

# cat /etc/postfix/base/taro/new/1490711394.Vfc01If0052bdM984614.3832cc77bd2d
Return-Path: <■■■@gmail.com>
X-Original-To: taro@oreore.com
Delivered-To: taro@oreore.com
Received: from oreore (メールの送信元 [172.17.0.1])
        by 3832cc77bd2d.oreore.com (Postfix) with SMTP id 73BDB60138FD
        for <taro@oreore.com>; Tue, 28 Mar 2017 14:28:57 +0000 (UTC)
from:■■■@gmail.com
to:oreore@oreore.com
subject:test mail

this is test mail for virtual user.

配送ユーザとしてvirtual(8)が選択されており,
「taro」というディレクトリにメールが保存されていることがわかると思う.
taroディレクトリは,存在しなければvirtual(8)が勝手に作ってくれる.
(baseディレクトリの権限を緩めたのはこのため)

その他,virtual(8)に関する細かい設定は以下参照.
Postfix manual - virtual(8)


以上,これでPostfixの仕組みと,基本的な設定は理解できた,気がする.
受信したメールはPOP3やIMAP4といったプロトコルで参照することになるが,
それはまた別のアプリケーションの話(dovecotとか)になるので,今回は割愛.


余談だけど,こういう実験の舞台準備としてdockerは超便利だなと実感.