福井情報技術者協会[FITEA]

■FITEA定期勉強会 第7回
■日時：10/18(土) 16:00～19:00
■担当者：朝井さん
■参加者：飛田さん、前田さん、堀内さん、森下さん
堂下(どのした)さん、朝井さん、小島さん、橋本
大久保さん
■内容

【自己紹介＋ネタ宣言】

堀内さん
今後入出、退出管理をすることになるので、
今後記入をお願いするかもしれません。

森下さん
RIAの紹介ができます

堂下(どのした)さん
初めての参加です。

橋本
　　VMWare ESXi のデモができます

大久保さん
　　2部からの途中参加でした。

■第一部：
SINGLETONパターン

唯一のインスタンスがサブクラス化により拡張可能で、
また、クライアントが、拡張されたインスタンスをコードの
修正なしに利用できるようにしたい場合。
→この部分についての議論を行いました。
→シングルトンクラスのインスタンス取得操作が、
派生クラスのオブジェクトを返すようにする。
そうすれば、クライアント側を変えなくていい

→Ｃ＋＋だと、シングルトンで取得できるインスタンスは
仮想関数の集合でないと実現できないのでは？
→バイナリ互換を保つのであればそうです。
→ソース互換であれば、変更時にvirtualを付ければＯＫ

シングルトンパターンとモノステートパターンについて

興味深いのはコンストラクタをプライベートにすると、派生できない
C++はそうですよね。Javaもそう？

シングルトンの実現方法
・普通に new する
・ローカルスタティックな変数とする
上記の実際のシングルトンを使う
生成順、破棄順、異常系を考えると
いろいろな事を考慮する必要がある
参照:Modern C++ Design のデザインパターン

ログをシングルトンパターンで実現するとどうなるか？
ビジネスロジックとしてどうか？
ログの本質はどうか？
アスペクト指向でログを出力する
Ｊａｖａのフレームワークでは、アスペクトを用いてる例がある

ログを出力とするのはどういうことか？
「善からぬことが起きたという情報」と
「善からぬことが起きたというエラー」は違うはず

Ｊａｖａではシングルトンを自分で作らず、
フレームワークがやってくれている。
→エンドエンジニアがシングルトンを考えてはいけない？

共有メモリやスレッドローカルなリソースのアクセスに
シングルトンパターンを利用するのはいいのか？
ロックとか考えると getInstance()にロック機能を
入れるのはおかしいのではないか？

シングルトンは使えない？
使えるけど、実際に使う例を探すのは難しい

■第二部：
参加者の特権ということで、概要のみの報告です。

森下さん
　　ＲＩＡ（Curl , Adobe Air / Flex , SliiverLight) の概要と
　　Flexのデモをしていただきました。

■【振り返り：KPT】
＜Keep＞
・今日はたくさんの人が参加してくれた（はじめての方3名）
・Modern C++ Design のデザインパターン(シングルトンパターン)は興味深かった
・発表者が不明な点を表明したので、みんなで議論できた
　　→発表者は分からないことを表明してくれてＯＫ
・言語間の話が多く出た
・デザインパターンを元に実装の話(実コード)がでるのは楽しい
・参加者それぞれの話をしてくれたのがうれしい
・時間通り進んだ。

＜Problem＞
・場所が狭かった
・TVとホワイトボードがかぶった。
・勉強会のレベル・方向性がちょっとわからなかった。

＜Try＞
・机の上にホワイトボードの紙を置いてみる
・参考文献の紹介をする

【今後の予定】
8回目：11/15(土) 16:00～19:00 森下さん Template Method
9回目：11/29(土) 16:00～19:00 前田さん Adapter
10回目：??/??(??) xx:xx～xx:xx 橋本さん

【実績ログ】
1回目： 7/12(土) 9:00～ 朝井さん Visitor
2回目： 7/26(土) 15:00～ 前田さん Iterator
3回目： 8/ 9(土) 9:30～ 橋本さん Composite
4回目： 8/23(土) 16:00～ 飛田さん StateとStrategy
5回目： 9/ 6(土) 16:00～ 徳山さん Command
6回目： 9/27(土) 9:00～ 堀内さん Abstruct Factory
7回目：10/18(土) 16:00～ 朝井さん Singleton

■FITEA定期勉強会 第6回
■日時：9/27(土) 9:00～12:00
■担当者：堀内さん
■参加者：堀内さん、朝井さん、前田さん、橋本さん、徳山
■内容

【自己紹介＋ネタ宣言】
いつも通り。

【前半：デザインパターンの輪講】
Abstruct Factoryパターン（初めての生成パターン）

まずは、デザインパターンの全体マップを表にして「生成、構造、振る舞い」の中で
今まで済んだところを示してくれました。

Abstruct Factoryを一言でいうと、部品群を生成するクラス（これがファクトリ）を
切り替えて使う、というパターンです。
※例としてはデータベース処理を切り替えて使うことをイメージしています。

・Abstruct Productクラスが部品のインターフェースを定義する

　たとえばDBのコネクションを抽象化したAbsConnectionProductをインタフェースとする。
　これを各DB向けに実装したもの（Concrete Product）は、SQLServerConnection,
　OracleConnection, …のようなイメージ。
　同様にトランザクションとか、レコードセットなどを抽象化したAbstruct Productと
　一式のConcrete Productも用意する。

・Abstruct Factoryクラスが工場のインターフェイスを定義する

　部品と同様に、SQLServerFactory, OracleFactory, MySQLFactoryなどが
　Concrete Factoryとなる。

　また、各Concrete Factoryの生成もこのインターフェイスの仕事。

普通ならClientはConcrete Productを選択して生成するが、このパターンを適用すると
１．Abstruct Factoryを通してConcrete Factoryを入手する。
　　※どのFactoryクラスのインスタンスを返すかは、引数などで指定することになる。
　　　（内部で設定ファイルを読み込むようにすると、指定しなくてもよくなる）
２．Concrete Factoryが実装しているインターフェイスを通して、各Productを入手する。
３．Concrete Productが実装しているインターフェイスを通して処理を行う。
ということになる。

Clientは、基本的にインターフェイスしか使わないので、実際のFactoryやProductが
SQL Server向けなのか、Oracle向けなのか気にする必要がなくなる。

＜どのような場合に使えるか？＞
・例のように、DBを切り替えるとか（実際は簡単な話ではないが・・・）

＜気になること＞
・Abstruct FactoryがConcrete Factoryを生成するところ。
　いわゆる「抽象クラスが具象クラスを知っている」というのが気持ち悪い。

　Concrete Factoryの名前付けが単純なルールであればリフレクションを使うと
　すっきりと実装できそうな気がする。

　現実的に、Factoryが非常に多くなることは想定していないのでは？
　（たとえばDBが100種類あったら破綻しそうな気がする）

・Factoryにしても、Productにしても、それぞれの具象クラスに必要な機能の最大公約数
　をとったインターフェイスが必要となる。そうでなければ、制限事項が出る。
　たとえばあるDBでConnectionが必要なかったとしても、ほかが必要としていれば
　空の実装などで用意する必要がある。

【後半：持ち寄ったネタでの雑談】
・橋本さん：自宅のテレビ録画サーバ紹介
・前田さん：バーコードリーダとAmazonのWeb APIを用いて本の価格を調べたり
　　　　　　出品したりできる自作システムの紹介
　　　　　　※バーコードリーダ、意外に盛り上がりました
・徳山：Androidの端末第１号、”G1″発表。10/22アメリカで発売。

【振り返り：KPT】
＜Keep＞
・事前にネタ宣言ができた
・ブログに書いてくれた参加者がいた（森下さん、朝井さん(社内)）
・デザインパターン全体マップが提示され、俯瞰することができた
・時間通りできた
・前田さんが午前中に来ることができた
・『数学ガール』、『プログラマの数学』の話があった
　今後のネタとして、本の紹介・感想などもおもしろそう
・バーコードリーダの話（製品・活用）がよかった
・地域情報の交換ができた（本屋、電器屋・・・）

＜Problem＞
・テレビが映らなくなることがあった
　ケーブルが長いから？（今までは問題なかったのに・・・）
・やっぱり新しい人がほしい。参加者が増えると話題や視点が広がるから。

＜Try＞
・テレビの短いケーブルを用意する（あった）
・ライトニング・トーク(LT)で勉強会の紹介をする
　（飛田さんが勉強会のLTをする予定。橋本さんも少し）

・別地域の勉強会へ出張参加するってのもおもしろそう
　（小島さん紹介の「IT勉強会カレンダーを見ながら）
　→行けそうなものを物色しておきましょう。

【今後の予定】
7回目：10/18(土) 16:00～19:00 朝井さん (テーマ未定)
　　☆朝井さんへ：テーマが決まったら周知してください。
8回目：11/15(土) 16:00～19:00 森下さん (テーマ未定)
　　☆不在なのに仮決めしてしまったので、
　　　森下さんに確認しています。
9回目：??/??(??) xx:xx～xx:xx 前田さん (テーマ未定)

【実績ログ】
1回目：7/12(土) 9:00～ 朝井さん Visitor
2回目：7/26(土) 15:00～ 前田さん Iterator
3回目：8/ 9(土) 9:30～ 橋本さん Composite
4回目：8/23(土) 16:00～ 飛田さん StateとStrategy
5回目：9/ 6(土) 16:00～ 徳山さん Command
6回目：9/27(土) 9:00～ 堀内さん Abstruct Factory

■FITEA定期勉強会 第5回
■日時：9/6(土) 16:00～19:00
■担当者：徳山さん
■参加者：徳山さん、橋本さん、堀内さん、浅井さん、森下さん、前田
■内容
　・自己紹介

　・前半：デザインパターンの輪講
　　commandパターン
　　・母親が子供に500円わたして、バナナ一房と牛乳1パックを近所のコンビニに買いにいかせるタスクについて、パターン化を試みる。
1)依頼する人、依頼される人、依頼、の3クラスに分ける
2)依頼クラスのサブクラスとしてお買い物クラスを実装する
これがcommnandパターンとなる。

　　　どのような場合に使えるか？
　　　・commnadパタンは、命令の内容をオブジェクトとして表現する。
　　　・命令が増えても、他の命令や依頼される人に影響が少ない。
　　　・命令としての使い道が広がる。
　　　　- 履歴として保存してundo, redo等の操作を行うことができる
→mementoパタン
　　　　- 複数のcommandパタンをまとめて扱う→compositeパタン
　　　　- ひとつの命令をたらいまわしに実行することができる。
　　　　 →visitor / chain of responsibilityパタン

　・後半：持ち寄ったネタでの雑談
　　　徳山さんがGoogle Androidエミュレータのデモ
　　　堀内さんが音声合成ソフトウェアのデモ
　　　・ペンタックス音声合成ソフトウェア(有償) http://voice.pentax.jp/17/23/
かな漢字まじり文をコピペしてそのまま音声に。
なかなか綺麗でびっくり。
　　　・AquesTalk http://www.a-quest.com/aquestalk/
かなを読み上げ。無料のWindows版を試してみたが、
ペンタックスのものとひけを取らない音質。
音声認識ソフトウェアJujiusのデモ
音声合成が良かったため、音声認識のほうはどうか？
　　　　ということで急遽デモ。

　・KPTの結果
Keep
　新しいネタがよかった（音声合成→音声認識）
　新しいメンバーが増えた♪
　Androidを見られた
　司会と議事録は、その場で決める（人が固定しないように）
　言語にとらわれずに純粋にオブジェクト指向の話ができた
　（C++/Java/Ruby/C#・・・PHPとかあるとおもしろい）
　お茶が冷えていた（ありがとうございます）
　GoogleのIT勉強会に載せる

Problem
　初めて参加して思ったこと。１部と２部に分かれていることを知らなかった。
　※PRが足りなかったのでは？
　時間配分がイマイチだった。
　（１部の時間が短かすぎた？）

Try
　次回予告で「１部：xxx」「２部：持ち寄りネタ（未定）」
　参加しますメールで、ネタを表明してもらえるとうれしい。

　いつの日か：勉強会の様子をオンライン中継／チャットなどしてみるのもいい
　かも。　　　　　（スティッカム）
　２部の時間配分を開始時点に決める。

　自分のブログなどに感想をかくのもいいね。（FITEAへのトラックバックとか）
　クローズドなサイトを作って、そこにPPTなどの資料を置くのはどうでしょう。

■今後の予定
　　　　日時　　　　　　　　　　　担当者　デザインパターン
　6回目： 9/27(土) 9:00～12:00 堀内さん Abstruct Factory
　7回目：10/18(土) 16:00～19:00 朝井さん (未定)
　8回目：??/??(??) xx:xx～xx:xx 森下さん (未定)

■実績ログ

　1回目：7/12(土) 9:00～ 朝井さん Visitor
　2回目：7/26(土) 15:00～ 前田 Iterator
　3回目：8/9(土) 9:30～ 橋本さん Composite
　4回目：8/23(土) 16:00～ 飛田さん StateとStrategy
　5回目： 9/6(土) 16:00～ 徳山さん Command

■FITEA定期勉強会 第4回
■日時：8/23(土) 16:00～19:00
■担当者：飛田さん
■参加者：飛田さん、橋本さん、徳山さん、新出さん、前田さん、朝井
■内容
　・自己紹介
　　自己紹介の際に、ちょっとしたネタ振りがありました。
　　　飛田さん：
　　　新出さん：iPhone
　　　橋本さん：末尾再帰
　　　徳山さん：
　　　前田さん：
　　　朝井　　：Webサービスの紹介

　・前半：デザインパターンの輪講
　　strategyとstate
　　　比較 － どちらも同じクラス図になるが、どこが違うのか？
　　strategy
　　　strategyとは？
　　　　戦略
　　　　アルゴリズムの交換が可能
　　　　ドラクエAIの作戦切り替えのイメージ
　　　どのような場合に使われるか？
　　　　JavaではDIを用いるため、意識して使うことは少ない
　　　　JavaのJDBCでは、SQLの種類に応じて抽象化された処理を切り替える
　　　　ソートのコンペア関数を切り替える
　　　デモ
　　　　じゃんけんゲーム
　　　　　作戦を切り替える(作戦を切り替える際に、1つ前の手を参照するケースも
　　　　　考えられる)
　　　類似したパターンをどのように区別するか？
　　　　strategy、state、adapter
　　state
　　　stateとは？
　　　　状態
　　　　状態をクラスで表す
　　　　状態によって振る舞いが変わる
　　　デモ
　　　　信号
　　　　　赤青黄の状態 － 状態を変えるのは信号自身
　　　　　　　　　　　　 状態変更も隠蔽される
　　　　　状態遷移のパターンは決まっている(青→黄→赤→青→…)
　　　　　信号管理機
　　　　　　信号のインスタンスを使うだけで、状態遷移を行う訳ではない
　　　　　　信号に基づくジャッジ(進めるか否か、など) も行わない
　　　　　信号表示器
　　　　　　信号を表示するのみ
　　　　　信号管理機が時間を進める
　　　　　　時間を進めるイベントに反応して、必要に応じて信号の状態を変える
　　　　　　状態遷移の時には、状態遷移を行うメソッドに自分自身を引数として渡す
　　　　　信号の実装
　　　　　　Ａ、Ｂ、の2種類がある
　　　　　　　Ａ；状態クラスが、振る舞いと状態遷移の2つを持つ
　　　　　　　Ｂ：状態クラスは振る舞いだけを持ち、信号の状態遷移は信号管理機
　　　　　　　　　という別のクラスに移管する
　　　　　　Ａの場合
　　　　　　　新しい状態が追加された場合には、全体を再コンパイルし、再テストする
　　　　　　　必要が生じる
　　　　　　Ｂの場合
　　　　　　　状態が追加された場合に、既存の状態には手を加える必要は無く、追加した
　　　　　　　状態と信号切り替え機のみの修正＋テストですむ
　　　　　　Ｂのケースにおける信号切り替え機の修正作業は相当大変なのではないか？
　　　　　　　→ 全体を再コンパイル、再テストするよりはマシ
　　　　　　　→ 企業ではＢが好まれるが、Ｂの方がコストが高くつかないか？
　　　　　　　→ 程度問題であり、ケースバイケースで、ＡとＢを使い分ける
　　　どのような場合に使えるか？
　　　　どのようなシステムでも、状態遷移を持っているので、使える
　　　　ただし、設計が悪いと大変なことになる
　　　　O/Rとはあまり相性が良くない
　　　まとめ
　　　　strategyは意識せずに使われているが、stateは意識して使わないと使えない
　　　　strategyは意識して振る舞いを選択するが、stateは意識せずに振る舞いが変わる

　・後半：持ち寄ったネタでの雑談
　　　新出さんが、iPod Touch上で動くアプリケーションのデモを見せてくれました。
　　　現時点では、iPod TouchやiPhoneの開発キットの入手には登録が必要で、
　　　また、契約内容にNDAが含まれることもあり、あまり詳しい話はありませんでした。
　　　SafariがJavaScriptに対応しており、加速度センサーの状態等も取得できるため、
　　　JavaScriptでアプリを作ると面白いのではないか？
(登録不要で、無償)とのこと。

　・KPTの結果
　　　ーKeep：良かったこと
　　　　自己紹介できた
　　　　時間を守れた
　　　　WLANが使えた
　　　　iPod Touchのデモが見れた
　　　　デザインパターンのデモがあった
　　　　議論が出来た
　　　　複数のパターンについて言及する議論が出来た
　　　ーProbrem：悪かったこと、失敗したこと
　　　　漢字が書けない
　　　　ネタしこみを忘れた
　　　　告知メール(2通目)の送信が遅れた
　　　　参加表明を忘れた
　　　ーTry：次回はこうしよう
　　　　Webに結果を掲載する(新出さん)
　　　　テレビ台があるとうれしい(堀内さんと要相談)

　・前回のＴｒｙについて
　　　ーテレビ台を用意する
　　　　→次回に持ち越し
　　　ー飲み物を事前に用意しておく
　　　　→用意できた
　　　ーUMLクイズのネタを持ち寄る
　　　　→出来なかった
　　　ーUMLの勉強をしてくる
　　　　→出来なかった

■次回以降のスケジュール(最低2回先までは予定を立てます)

　　　　日時　　　　　　　　　　　担当者　デザインパターン
　5回目：9/6(土) 16:00～19:00 徳山さん Command
　6回目：9/27(土) 9:00～12:00 堀内さん (未定)
　7回目：(未定)　　　　　　　　 朝井　 (未定)
　8回目：(未定)

■実績ログ

　1回目：7/12(土) 9:00～ 朝井 Visitor
　2回目：7/26(土) 15:00～ 前田さん Iterator
　3回目：8/9(土) 9:30～ 橋本さん Composite
　4回目：8/23(土) 16:00～ 飛田さん StateとStrategy

FITEA会員の中で学習意欲のある有志が集まって、定期的な勉強会を自主的に開催しています。

開催は主に土曜日の午前中or午後で、隔週又は3週間置きとなっています。
現在のメインテーマは「デザインパターン」。これを基本にしつつ、毎回そこからいろんな話題に発展してゆきます。

詳しくはこちらをどうぞ。
http://fitea.org/?page_id=80

最近の開催ログと予定は、以下の通りです。8/23の夜は飲み会があるかも？

1回目：7/12(土) 9:00～ 朝井 Visitor
2回目：7/26(土) 15:00～ 前田さん Iterator
3回目：8/9(土) 9:30～ 橋本さん Composite
4回目：8/23(土) 16:00～19:00 飛田さん StateとStrategy
5回目：9/6(土)　16:00～19:00 徳山さん (未定)
6回目：(未定)　　　　　　　　　堀内さん (未定)
7回目：(未定)