netail.net

_ メール ▲

年度が変わったので，所属も変わった．ということでメールの署名をすべて変更．

基礎工学研究科 情報数理系専攻 → 情報科学研究科 コンピュータサイエンス専攻と若干長くなったので面倒ではあるが．

アドレスも ics.es.osaka-u.ac.jp からist.osaka-u.ac.jp に変わった．これで，投稿論文の所属等が先生と全部統一できる．

_ 論文 ▲

修士論文の原稿を削って投稿用の論文を作成．２段組で15ページだったものが８ページまで圧縮された．

先生に直される部分がほとんどなかったので，ちょっと自信がついた．現在のエラーチェックリストは次の通りだが，機械的にチェックできるところはチェックしてみたい．paper-lint みたいなのを作れないかなぁ．

・過剰な句読点・継続した文の途中改行・曖昧な指示代名詞・離れた段落を指示する代名詞・曖昧な接続・同じ語尾の連続・過剰な形容詞・冗長な表現

_ AOSD 2003 ▲

AOSD2003 の Proceedings が ACM Digital Library で公開された．ということで，さっそく先生に入手してもらうようねだってみる．本当は素直に学会員になればいいんだが，手続きが面倒なのでしばらく先生に頼ることにする :-)

_ 通販 ▲

とあるサイトで，ワインのメールでの購入ができるというので，メールで注文を投げてみたが，返事が３日経っても来ない．サイト自体は生きてる様子なのだが，３日で返事が来ないというのは他の通販専門系のサイトに比べて圧倒的に遅いので，ちょっと不安だったりする．

_ 年金 ▲

年金を払い込みに銀行へ．なんとATMから引き落とした金を窓口で振り込むという馬鹿げた行動をさせられる．郵便貯金ではきちんと振り替えのための用紙を準備してくれているのに……．しかも，ATMコーナーから一時的に（わずか数メートルだが）建物の外に出る上，警備員などはいないので，大金を持って歩くのは精神的によろしくない．

_ AOSD 2003 ▲

AOSD2003の Proceedings は，ACM Digital Library の"Public" カテゴリで公開されていたため，誰でも取れる，無料の ACM Web Account だけとってしまえば閲覧できた．必要なところだけ印刷して読むことにする．

_ ワイン ▲

ハッピーキャット・黒猫ボトルワインが到着．ワールドワイン http://www.world-wine.co.jp は，ちょっと最初の反応が遅かったことを除けば，梱包もしっかりしてるし，納品書もちゃんと書いてるし，けっこう真面目な感じが好印象．

そもそも，ハッピーキャット自体がわりと品薄っぽいので手に入ったこと自体幸運だったかもしれない．

ワイン自体は贈り物用なので，デジカメで記念の写真だけ撮影して箱に戻して，贈る日まで保存することにする．

_ apache ▲

気付いたら朝から oucc.org の httpd が落ちていたので，ログインして再起動させる．エラーログを見てたら ruby が core dump してたから，例によってmod_ruby あたりが怪しい．

_ AOSD 2003 ▲

ツール改良のかたわら，AOSD2003の論文読みを開始．とりあえず，一番最初のM. Katara, Shmuel Katz: ``Architectural Views of Aspects''から読んでみた．

アスペクト間のオーバーラップする部分をSub-Aspectと呼ぶ．で，依存辺を 独自部分→共通部分 という向きでアスペクト間の依存関係を記述する Concern Diagram を作成する．この論文では，Concern Diagram というのを UML 上で使う例を掲載している．

Concern 間の関係を書く，というのは今まで見たことがなかったような気がするのだけど，逆に言うと図の作り方だけという印象．まあ，アーキテクチャのレベルなので詳細な使い方があるほうがおかしいが．

この論文の筆者たちは，小さなアスペクトをたくさん定義して，システムごとに最適なアーキテクチャを構成するようなことがしたいらしい．また，アスペクトを Concern Diagram 上で定義しておいて，共通アスペクトだけを定義しさえすれば，disjoint なアスペクトはそれぞれ並行して開発できる，とか．

まあ，これは興味の範囲外，かも．ただ，アスペクトマイニングなどで得られたアスペクトをこうやって図で表示できたりしたら格好いいかな？

_ ダイス ▲

サイコロを５個振って出た目がポーカーの役になるかどうか，という話になって，それをテストするスクリプトを書いた．素直に確率計算すればいいのに総当り．

結果は，以下の通り．

ファイブカード: 6通り

フォーカード: 150通り

ストレート: 240通り

フルハウス: 300通り

ブタ: 480通り

スリーカード: 1200通り

ツーペア: 1800通り

ワンペア: 3600通り

合計: 7776通り

_ AOSD 2003 ▲

AOSD2003論文読みの２本目．

A. Rashid, A. Moreira, J. Ara\acute{u}jo: ``Modularisation and Composition of Aspectual Requirements'',Proceedings of the 2nd international conference on Aspect-oriented software development, pp.11-20, Boston, Massachusetts, March, 2003.

要求分析で用いられるRequirement Engineering (RE) に，アスペクト指向的なアイディアを導入するという話．複数の要求を横断したような concern をどうやって分離・再構成するかというのが問題らしい．

具体的には，視点（"利害関係者"）ごとにどの Concern が重視されるかを最初に調べる．次に，Concern 間の positive/negative な影響をリストアップし，同時には成立できないような要求(Conflict)に対しては優先順位の決定によって順次解消していく．

Conflict がなくなったら，Concern をプロダクト中の機能・設計・アスペクトといった要素にマッピングしていく．この論文では，要求分析段階での Concern を，"candidate aspect"と呼んでモジュールのアスペクトと区別していた．

で，この筆者らの手法では，要求を XML 形式で，Viewpointごと，およびConcernごとの要求定義を行う．そこから，どの要求が満たされなければならないかという制約＜Constraint＞と，その制約によって何が得られるか＜Outcome＞を記述したComposition Rule を作成する．で，ツールでXMLをparseしてConflictを検出し，ユーザが設定した要求の優先度によって解消を行う．

Viewpoint と Concern という二つの軸で要求を分析するところがアスペクトと似ている．ちなみに，最終的に確定した Concern は，アーキテクチャ，設計，機能（クラスやアスペクト）といった様々な場面に影響する．モジュールとしてのアスペクトを発見するための手法ではない．

_ 読書 ▲

リチャード・S・ワーマン「それは情報ではない」を読了．データ，情報，知識，知恵の区分といった概念的な話から，情報の伝達，コミュニケーション，職場での人間関係まで，有益な示唆を含んでいる．情報の伝え方，という意味では論文の書き方などにも関連してくるので，ちゃんと内容が消化できるまでは手元に置いておくことになりそう．

_ 本 ▲

人に貸してたA.ハント，D.トーマス「達人プログラマー」を返してもらった．アスペクト指向プログラミングに出会った思い出の本である．といっても，単に「ハンプティ・ダンプティは事故死か他殺か」のくだりが読み直したくなっただけだが．

_ AspectJ ▲

aosd-discuss メーリングリストで，Concern って何，という話が出ていた．

それに対して，Ana Moreira が次のようにまとめていた．

Message-ID: 00fb01c2ff46$bd31b420$0100a8c0@microrede.pt

List-Archive: http://aosd.net/pipermail/discuss/

Subject: Re: [aosd-discuss] How determine what is crosscuting in requierements level

A concern is anything with interest for a system; therefore, a concern may be a functional requirement or a non-functional requirement. Any requirement(functional or non-nonfunctional) can be described in terms of other (sub)requirements. So, you have requirements at different levels of granularity.

A concern cuts across another concern (is crosscutting) if one is related with the other, or needed in the other.

_ 工事 ▲

家の前でガス管の夜間工事をしてるので，寝不足．派手な音はしないが，ライトの明滅がうっとうしい．

_ bun45 ▲

バイト代の支給と，ミーティング．

なぜかファイルのうち削除できないものがある，という謎の報告を受け取ったので，原因を調査することにする．とりあえず，忘れないようにここに必要なデータだけメモしておく．NiemeyerSirOttoErnst.xml

_ 料理 ▲

人に勧められて，朝食はリンゴのソテー（単に薄く切ってバターで焼いたともいう）と食パン．食べてみたら，アップルパイの簡易版みたいな感じだった．欠点は，リンゴが１個だと量が多いことだろうか．一部，アップルティーにするというのもありかも．

_ bun45 ▲

なんと，データを削除する直前に確認を取るためのデータ表示を行っていたのだが，そこで参考文献データのparseに失敗していた．昔，データ形式を変更したときに変更し忘れたものらしい．結局，参考文献を持ったデータが削除されることがなかったためにいまさらバグが発現したということだった．事前テストで検出できたはずのバグなので，ちょっと恥ずかしい．

_ 出張 ▲

アメリカへの出張準備，の前段階として親の了承確認が入った．いちおう情勢の不安定を受けての措置らしい．ってことで，親にメールを送ってみた．しかし，緊急というほどでもないが，気になるので仕事から戻ってくるあたりで連絡がなければ素直に電話してみよう．

_ メーラー ▲

Al-MailからBeckyへ移行するかどうか考えるために，軽くBeckyをつついてみた．オプションなどを見た限り，使い勝手はよさそう．4000円程度のライセンス料も今となっては安いものだ．学生の間はAl-Mailでもいいかもしれないが．

Al-Mailのメールを選択して「ファイル保存」でmbox形式出力してBeckyに食わせればいちおうメールの移行はできるらしい．各フォルダごとに実行しなくてはならないので，それなりに手間はかかりそう．

_ お菓子 ▲

昼前に府議会議員選挙の投票に行く．近所の小学校が投票所だったが，桜がちょうど散り際で綺麗だった．

で，帰ってきたところで来客．chez copainのマンゴープリンと苺のゼリーっぽいケーキ．どっちも見た目が華やかだった．最近，お菓子をたくさんもらうのだが，甘いものを普段は控えている人がお菓子を買うダシにされてる感がある．もちろん，タダであちこちの新作ケーキが食べられたりするので，文句を言う筋合いはないのだけど．

_ 論文 ▲

輪講で使った論文：Damien Sereni, Oege de Moor:``Static Analysis of Aspects'',Proceedings of AOSD 2003.コールグラフを構築して，呼び出し関係の正規表現に直して，Pointcut 定義との包含関係を取ったらアドバイスを静的に結合できるね，という話．正規表現との包含関係については，Chip-Chop Matrix というものを使って計算できるらしい．Oege de Moor, Stephen Drape, David Lacey and Ganesh Sittampalam:``Incremental Program Analysis via Language Factors''という論文に載っていた．もし使うことがあれば見ることにしよう．また，正規表現を生成する Tarjan のアルゴリズムというのも使われている．ポインタだけメモ．R.E.Tarjan: ``Fast algorithms for solving path problems'',Journal of the Association for Computing Machinery, 28(3):594-614, 1981

とりあえず，静的解析コストが高くて（正規表現の包含関係のテストが重い）スケーラビリティがあやしいというのだけは確かだが，予備知識へのポインタが色々あって面白い．

_ AOP ▲

AOPでは，ソースをカット＆ペーストした場合に，その位置の join point が違うからアスペクトの動作が変わってしまってプログラムがうまく動かなくなる場合があるよね，という話をAspectJ-Users ML に Tim Pedone という人が投稿していた．実は，けっこう重要な話かも．「どこにアスペクトが貼りついてるかを常に意識する」のを開発環境でフォローするときの動機のひとつとして使わせてもらうことになりそう．

_ 花見 ▲

造幣局の桜の通り抜けに行ってきた．天気もよく，色々な種類の桜が満開で，満足．ちょっと混雑の度合いがひどいような気はするが．

帰りにロンドンティールームでスコーンを食べて休憩してたら，研究室の事務から呼び出されてすぐに帰還することに．ちょっとショックだった．

_ AOSD2003 ▲

Karl Lieberherr, David H. Lorenz, Pengcheng Wu:``A Case for Statically Executable Advice:Checking the Law of Demeter with AspectJ''

Law of Demeterをチェックするために，コンパイル時に実行可能なアドバイスを書けるようにしてみようとかいう感じの話．当然ながらJoinPoint.StaticPart だけに依存して実行できるものだけに限られるが．

AspectJのdeclare warning とかの上位バージョンと言えないこともない．

Law of Demeter とは：

1. Class Formあるクラス C のメソッドは，以下のメソッドにしか依存してはならない．

・C のほかのメソッド

・C のメソッドの戻り値のクラスのメソッド

・C のメソッドの引数のクラスのメソッド

・C のインスタンス変数のクラスのメソッド継承クラスは，Cの一部だからどう呼んでもいいのかな？忘れてしまった．

2. Object Formあるオブジェクト o は，以下のオブジェクトにしかメッセージを送ってはならない．

・o 自身

・o に引数として渡された変数

・o のインスタンス変数

・o の中で構築されたローカルオブジェクト

・o 自身のメソッドの戻り値のオブジェクト

これは，守る側も検査する側も大変なので，アスペクトとして検査を書くのだが，できればコンパイル時に検査までやってしまいたいよね，という話．

この論文では特に述べられていないようだが，アスペクトも Law of Demeter に従うべきなんだろうか．オブジェクト指向とはそもそも考え方が違う，という話もあるが……．

_ AOSD2003 ▲

Sean McDirmid, Wilson C. Hsieh:``Aspect-Oriented Programming with Jiazzi''

Jiazziという言語の紹介に近い論文．

signature としてクラス群のシグネチャだけを定義する．atom というのが接続単位で，atom は import, export で入出力ポートを宣言する．import, export のインタフェース指定に signature を使う．で，link unit1, unit2; という形式で atom 間を接続できる．

signature は， sigunature new_sig = old_sig + { .. } という形式で拡張できる．

実装ファイルは，atom名/sigunature名/クラス名 のような形式になるっぽい．

型パラメータもサポートしている．name [DEVICE];class [DEVICE] extends .. { void set[DEVICE]([DEVICE] dvc);}というように記述しておいて，実装サイドではvoid setDEVICE(DEVICE dvc) を実装する．で，後からsignature hoge = foo + { [DEVICE] = Spell;}というようにしてパラメータを与える．

基本的には Hyper/J や mix-in のアイディアに近くて，利用関係をプログラマが明示的に書けるところがやはりポイント．クラス間の利用関係，継承関係を接続できるところが面白いかも．

_ 背景については OOPSLA2001の論文を読め，ということらしい． ▲

S. McDirmid, M. Flatt, and W.C. Hsieh:``Jiazzi: New-age components for old-fashioned Java'',In Proc. of OOPSLA, Oct. 2001

_ AspectJ ▲

とりあえず，AspectJ のインストール方法をドキュメントに追加．別にこの程度，まとめてくれてるサイトは他にもあるのだが，初めて使う人に向けた情報も載せよう，ってことで．

_ AOSD2003 ▲

タイトルに興味を引かれてしまった論文．Stefan Hanenberg, Rainer Unland:``Parametric Introductions''

Introduction中での自己参照thisはどう扱うべきか？もし結合対象のクラスを指すとしたら（わりと妥当な判断だが）abstract introduction(結合対象クラスが，まだそのアスペクトでは未確定のintroduction)では型チェックができない．weave-timeよりも前にthisの型が決定できればうれしい，というのが動機．

Introductionがうまくいかない例として，Singleton, Visitor, Decoratorが掲載されている．Singletonは，オブジェクトを返すときのシグネチャが具象クラスに設定できないので型キャストが必須になる．他も，結合対象クラスの存在をアスペクトが知らないと対処できない．

で，この筆者らの提案は，一言で言えば?class と書いたところがweave対象クラスの名前になる，というようにパラメタライズして，?class を戻り値や引数の型として使う．そして，pointcut target(): equals(?class, A)||equals(?class, B);というようにしてパラメータと実体名をバインドする．

Introductionに対してどういう検査が有効だとか，そのときにIntroductionのタイプに応じてどう影響があるか，とかは将来の課題．

_ AOSD2003 ▲

さらに論文読みは続く．Erik Ernst, David H. Lorenz:``Aspects and Polymorphism in AspectJ''

オブジェクトの型に合わせて，適切なアドバイスのうちひとつを実行したい，といった要求があるが，そのときに今のAspectJでは ad hoc な方法しかないので何とかしたい，という話．で，アドバイスに名前を付けてグループ化しておき，そこから適切なものを選ぶということを提案している．また，オブジェクトの従来の多態性のかわりに，各アスペクトがintroductionを使ってクラスに必要な実装を与えよう，とか言っている．

_ AOSD 2003 ▲

AOSD2003本会議の論文（の中で興味を引いたもの）はこれで最後．

Mark C. Chu-Carroll, James Wright, Annie T. T. Ying:``Visual Separation of Concerns through Multidimensional Program Storage''

発想は，Separation of Concerns を，「言語的に分けずに，見た目的に分ける」というもの．

必要なのは，クラスより細かい単位でのストレージへの保管，複数のソースフラグメントの集約，動的なフラグメントの選択，フラグメントを認識するエディタ，などなど．

この論文では，「ツールの見た目こんな感じ」というスクリーンショットがやっぱり Eclipse ベースで作られていて，すごく格好よさそうに見える :-)

個人的な好みで言うなら，アスペクトとオブジェクトを分離しておいて，オブジェクトを見るときはアスペクトのコードがあたかもそこにあるかのように（灰色などで）見せる，というのもアリかなーと思うのだが，Visual C# などのコード「折りたたみ」機能などと同様に実装されないものだろうか．

_ AOSD 2003 ▲

だんだん読むのにも疲れてきたのでざっと斜め読み．

Doug Janzen and Kris De Volder:``Navigating and Querying Code Without Getting Lost''

JQuery による検索ツールの実装．Query としてはpackage( ?P, type, ?T) のように"?"で始まる自由変数を満たすノードを見つけてくる Prolog のような言語で書く．パッケージ，型，メソッド，どのメソッドから参照されているか，といった情報が使える．

クエリー結果はツリー構造で表示されるが，その中からさらに検索するときは，ツリーを「接木」していくと検索プロセスが分かる，とか言っているあたりが面白いかも．

ちなみに，プロトタイプは Eclipse ベース．クエリーを直接書くのは面倒だから，何か適当なラッパーを間にかませばすごく便利になりそうな予感．

_ AOSD 2003 ▲

AOSD2003の論文はこれを読んだところであと二つ．もっとも，併設ワークショップの分がさらにあるのだが．

David B. Tucker, Shriam Krishnamurthi:``Pointcuts and Advice in Higher-Order Languages''

Scheme で pointcut 定義や advice の定義をしている論文．pointcutがlambda定義されてるあたりが格好いい．(lambda (jp) (and (eq? f (first jp)) (memq g (rest jp))))とかいう感じで順番に構築していってる様子が説明してある．

この様子を見ている限りでは，Scheme ではかなり頑張れるみたい．ただ，関数型特有の性質について触れてなくて，lambda をカリー化していったときはどうなるのか，とか色々気になるところは残ったまま．今後に期待したい．

_ AOSD2003 (下の続き) ▲

JAsCo のシステムでは，Beans を必要以上に操作しないので，動的にアスペクトの取り外しができる．逆に，アスペクトを回避して元の実装を呼ぶ，という処理は使えなかったりする（そのあたりはコネクタでうまく回避する必要がある）．

ツールとして，Visualにコネクタをつないだり外したりする環境もあるらしく，それを使うと格好よくアスペクトの付け替え作業ができそう．何より，動機，モデル，言語要素が理解しやすいのがポイントかも．JAC よりも良くまとまっている気がする.

さりげなく，将来の課題のところに .NET のMSILにも対応してみたいなぁ，とか書いてあって，もし実装されたら一回は使ってみたいかも．

ちょっと気になるところは，コネクタを定義するのが，アスペクトが多くなると意外と大変なのではないか，というところと，アスペクトに対するアスペクトを書くときなんかに怪しげなことが起こったりしないのか言及がないところ．まあ，実際の開発言語として使われるようになったら，もっと利点や弱点が分かるかも．

_ AOSD2003 ▲

論文読みは続く．Davy Suv\acute{e}e, Wim Vanderperren, Viviane Jonckers:``JAsCo: an Aspect-Oriented approach tailored for Component Based Software Development'' コンポーネントベースの世界(とりあえずこの論文ではJava Beansが材料)では，コンポーネント，アスペクトの再利用性は非常に重要．しかし，今のアスペクト指向では，アスペクトの結合基準の記述がアスペクトの定義にくっついていて再利用性が低かったり，コンパイル時に結合するので動的な特性を持ったシステムでは利用できなかったりする． そこで，JAsCo 言語では，アスペクトとして次のように定義する．

class AccessManager {    hook AccessControl {    AccessControl(method(..args)) {      executes(method);    }    replace() {      if (p_db.check(currentuser, object) {        return method(args);      } else {        throw new AccessException();      }    }  }
  :  // other methods and fields, shared by hooks
}

この hook に対して，コネクタを定義する．

connector PrintAccessControl {  AccessManager.AccessControl control =     new AccessManager.AccessControl(* Printer.*(*));}

ここで，コネクタは結合対象を定義する．また，複数のアスペクトを結合したいときは，ConnectionStrategy というインタフェースを使って「１個目のアスペクトが動作しなければ二つ目も動作しない」といった処理を定義できる． 基本的には動的処理で，バイトコード変換を使って普通の Java Beans にアスペクト用のフックを埋め込み，そのフックに到達するとコネクタ・レジストリを探して，マッチしたらアスペクトを実行させる，といった形になる．

_ 新歓 ▲

研究室の新歓．とりあえず先生方がお金をたくさん出してくれたので安く済んだ．研究室によっては数万円出す人もいるようで，なかなか大変だ．

_ 事務手続き ▲

COEリサーチ・アシスタントの手続きに，銀行の通帳＆印鑑，それに源泉徴収表と，色々準備しないといけないらしい．うう，この手の書類準備はやっぱり苦手だ．

_ 指輪物語 ▲

The Lord of the Rings RPG のルールサマリなどをアップロード．急ぎで作ったものなので抜けも多いような気はするが，いちおう遊べないことはない……たぶん．

_ カード契約 ▲

シティバンクのクリアカード(VISA)を作ってみた．別に他でもいいといえばいいのだが……．とりあえず，学生のうちにいくつか試してみる方針．

それにしても，住所と本人確認のためだけに待ち時間のほうが長い電話をするって馬鹿げてるような気がする．電子署名＋住基ネットでの住所確認とかできるようにならないかな．できたらできたで危険な気はするが……．指定された住所と氏名が対応するか yes/no を返すクエリーくらいなら担当してくれてもいいような気がする．

_ 健康保険 ▲

保険証の切り替え（扶養家族からの資格喪失）手続きがあるので保険証を実家に送り返した．あとは，資格喪失証明書が届き次第，国民健康保険への加入をする．

移行期間の保険ってどうなるんだろう……．普通は病気の間に移行なんてしないとは思うけど．

_ 学振 ▲

学術振興会特別研究員の申請書を作成．実績がほとんどないので厳しいが，運良く通るといいなぁと思いながら真面目に書類を作る．

_ Windows ▲

緊急のセキュリティホールが出たので，例によって Windows Update をかける．実際には，ニュースを読むよりも早く自動更新でダウンロード済みだったりするのだが．

それにしても，研究室と下宿であわせて４台もセットアップさせられるのだから，さすがに手間だ．

_ スパム ▲

今日はなぜかスパムメールが大量に届いた．送る側はどうせ自動的に送ってるんだろうから，性質が悪い．

_ 新歓 ▲

oucc の新歓コンパ．それなりにビールだけ飲む．50人もいると，さすがに食べ物はほとんどない．

毎年，敬語を使わない（使えない）１年生がいるのは仕方ないが，酒をつがれるときにグラスをどんと立てておくだけの（お礼も言わない）人間は初めて見た．放っておくと手酌で飲むし，ほとんど喋らないし（後半見てなかったけど），何なのだろう．

まあ，全体としては，人数も多くて，わりとノリのいい人間も多いので，それなりに好印象の学年ではある．問題は，何人残るか，だが……．

_ AspectJ ▲

AspectJ 情報で，若干，誤植等を訂正．

_ Java ▲

今日のはまり．

Javaで，更新したデータファイルを読み込んでくれないので調べてみたら，if (File.canRead(project_dir + "/hoge")) { f = new FileInputStream(CONSTANT + "/hoge");}というようなコードになっていた．CONSTANT -> project_dir で置き換えたときに，そのまま放置していたらしい．

_ 来客……のはずが ▲

来るはずの人が風邪をひいたとかで，来客の予定はキャンセル．午後は丸々空けていたので，意外と暇だ．読書用の本が部室に置きっぱなしなので，取りに行くことにする．

_ マシン整備 ▲

マシンといっても単にパソコンだが．そろそろ無用になりつつあった SCSI 1GB をはずして，以前はNLXマシンに収めていた60GB IDEを追加．

このSCSI 1GBのディスク，今はなきICMの外付けSCSIで（中身はIBM製だが），買った当時は３万円くらいしたもの．今となっては，ほとんどゴミかもしれない．

_ 選挙 ▲

市議会議員選挙．とりあえず，車で音を鳴らさなかった人，という基準で大まかにふるいをかけてから投票．選挙が終わったので，少しは静かになるだろう．

_ 読書 ▲

Deborah G. Johnson著，水谷 雅彦，江口 聡 監訳「コンピュータ倫理学」読了．

道徳と法律，記述的な話と規範的な話の切り分けなど，判断基準に関する示唆をたくさん含んでいる本．文字ばかりなので読むのは疲れたが，それなりの知識は手に入った，と思う．暇があったら何度か読み返したほうがよいかもしれない．

_ 読書 ▲

紅茶を買うついでに買ってきた，アン・マキャフリィ，パーンの竜騎士外伝３「ネリルカ物語」読了．ということで，これでパーンの竜騎士シリーズの日本語訳はコンプリートしたことになる．あとは手を出すとしたら，未訳の資料集系だろうか．

_ 紅茶 ▲

祝ダージリン・ファーストフラッシュ発売．ということで，今年はアリヤ 50g，去年個人的に大当たりだったミリクトンを50g を購入．どうやら，農園指定のは入荷量が 150kg 程度に限定されているらしい．たぶん，来月頃には売り切れてるだろうから，ちょっと残念だ．かといって，好みとは限らないので100g 単位で仕入れる気にもならない．

定番となりつつあるディクサムも仕入れて，紅茶代金は5000円．

帰って早速アリヤを試飲してみたが，かなりいい感じ．ミリクトンとどっちがいいかな？