読書会(APIデザインの極意)第5回議事録

=====================================================================================
Java読書会BOF 「APIデザインの極意 Java/NetBeansアーキテクト探究ノート」を読む会第5回
=====================================================================================

.. csv-table:: 開催概要

   "日時", "2015年2月14日 10:00 - 17:00"
   "場所", "川崎市教育文化会館　第３会議室"
   "出席者(敬称略)", "高橋(徹)、遠藤、井上、門脇、平山、松永、吉本、岩室(書記)"

第10章　他のAPIとの協調
-----------------------

10.6 JavaBeansのリスナーパターンを使いすぎない
----------------------------------------------

* JavaBeansの仕様書を探すと意外と大変。

* (p.194) サンプルコードの「実装」は、必要に応じてここを書け、という意味?

* 基盤側だけがリスナーを提供するなら、JavaBeansの仕様に合わせるのではなく、極力シンプルにした方が良い、という話。

第11章 API実行時の側面
----------------------

* Windows Vista以降での「C:\Windows」や「C:\Program Files」のファイル仮想化も、これに近い話(=見掛け上の動作に変更がない)と言える。

11.1 叙事詩を修正する
---------------------

* 「魔法使いにちなんで名付けらえてたソフトウェア会社」って何? (読書会中には調べが付かず)

11.2 信頼性と無知
-----------------

11.3 同期とデッドロック
-----------------------

11.3.1 スレッドモデルを文書化する
---------------------------------

* 「FindBugs & Co.」とは何?
  *  FindBugs用のアノテーションと絡めて話している?
  * 「××× & Co.」で「××xとその仲間」みたいな意味もあるらしい。

11.3.2 Javaモニタの落とし穴
---------------------------

* デッドロック対策のソリューション?
  * シェアードナッシング
  * Erlang
  * Actor
  * CSP(Concurrent Sequential Processes)
  * リアクティブプログラミング/RxJava

* p.209の例は何をやっているか? ⇒ サブクラスに干渉されないロックの仕方の例。LOCKのロックはサブクラスからは取れない。

11.3.3 デッドロック条件
-----------------------

11.3.4 デッドロックテスト
-------------------------

* 必ずしも再現するとは言えないのでは? ⇒ 確実とは言えないが、1000ミリ秒オーダーなら、ほぼ再現すると思われる。

11.3.5 競合状態をテストする
---------------------------

11.3.6 ランダムな失敗を解析する
-------------------------------

11.3.7 高度なロギングの利用方法
-------------------------------

11.3.8 ロギングを使用する実行フロー制御
---------------------------------------

* 実に「hack」ですね。

11.4 リエントラント呼び出しに対して準備する
-------------------------------------------

* 2行目「synchronized予約【語】を追加するだけで」(【語】が抜けている)

11.5 メモリ管理
---------------

.. note:: 次回は p.234「リスナーは参照で保持すべき」から。

[ 戻る ]