研究 Archive

「ICSOC」という国際学会について調べてみました。

ICSOCとは「International Conference on Service Oriented Computing」の略で、サービスオリエンテッドコンピューティングと呼ばれる分野を取り扱う学会です。
http://cgi.cse.unsw.edu.au/~soc/icsoc08/

2002年から開催されている、比較的新しい学会のようです。

サービスオリエンテッドコンピューティングとは、

ソフトウェアアプリケーションの設計・構築・配布・消費の方法を変える分散コンピューティングのための、新しい学際的なパラダイム
（Service oriented computing is an emerging cross-disciplinary paradigm for distributed computing that is changing the way software applications are designed, architected, delivered and consumed.）

を指すみたい。（日本語訳まずくてごめんなさい）。

「Call for Research Papers」を読んでみたところ、以下の分野に関する研究発表・論文を募集しているようです。
（メモ代わりに書きましたが日本語訳まずいところたくさんです。ごめんなさい）

• サービス基盤（Service Foundations）
• サービスの概念の、形式的で明確な定義（Formal and precise definitions of the notion of service）
• サービスのためのモデル技術と規格（specification and modeling techniques for services）
• モデル駆動のサービス開発（model-driven service development）
• 機能的、非機能的な品質の側面（functional and non-functional quality aspects）
• 形式的な組織の関係（formal composition relations）
• リスク査定と品質保証（risk assessment and quality assurance）
• 改良とリファクタリング（refinement and refactoring）
• プログラミング・実行モデル（programming and runtime models）
• 互換性と適合性チェック（compatibility and conformance checking）
• セキュリティと信頼性（security and trust）
• 変更管理（change management）
• ビジネスサービスモデリング（Business Service Modeling）
• ビジネスゴールと要件のキャプチャリングのための方法とツール（Methods and tools for capturing business goals and requirements）
• ビジネスサービスへの分解（decomposition into business services）
• ビジネスプロセス（business processes）
• ビジネスポリシー（business policies）
• ビジネスモデリング（modeling）
• ビジネス解析（analysis）
• ビジネスシミュレーション（simulation）
• サービスを用いたシステムの統合システム（Integrating Systems of Systems using Services）
• 統合アーキテクチャのための解析・設計技術（Analysis and design techniques for integration architectures）
• サービスとSOAのためのアーキテクチャとデザインパターン（architectures and design patterns for services and SOAs）
• 連合した認証と権限（federated authentication and authorization）
• データとサービスの分散（data and service distribution）
• ストレージと計算の仮想化（virtualization of storage and computation）
• 分散SOAのポリシー管理と統治（policy management and governance in distributed SOAs）
• サービスのライフサイクル管理（service-lifecycle management）
• サービス統合オントロジー（service integration ontologies）
• 変更管理（change management）
• サービスのモビリティ（mobility of services）
• サービスエンジニアリング（Service Engineering）
• サービスの記述（service description）
• 発見（discovery）
• コンフィグレーション（configuration）
• サービスマイニング（service mining）
• サービス開発・管理・検査・検証のための手法・ツール（service mining, methods and tools for service development, governance, verification and validation）
• サービスに関する情報誘出（information elicitation about services）
• サービスの告知（service advertisement）
• 意味ベースのサービス発見（semantics-based service discovery）
• 組織化されたサービスの発見（orchestration discovery）
• 制約のある仕様・施行（constraint specification and enforcement）
• サービスの構築（Service Assembly）
• サービスの開発と発見（Service development and discovery）
• サービス構成アーキテクチャ（service composition architectures）
• サービス・リソースのレジストリと関連づけられたメタデータ（service and resource registries and associated metadata）
• サービスの起動・通知のための標準・技術（standards and technologies for service invocation and notification）
• 意味的なマッチング・契約・交渉（semantic matching, contracting and negotiation)
• 構築のための展開戦略（deployment strategies for assemblies）
• サービスの配布とインストールのための戦略とアーキテクチャ（strategies and architectures for service delivery and installation）
• 展開トポロジと関連づけられたメタデータ（deployment topologies and associated metadata）
• サービスのバージョニングとアップデート（service versioning and update）
• サービス管理（Service Management）
• サービスに関連したデータの集合（Instrumentation and service-related data aggregation）
• エンドツーエンドの測定・解析・キャパシティプランニング（end-to-end measurement, analysis, modeling and capacity planning）
• 展開トポロジの定義（definition of deployment topology）
• インフラのコンフィグレーション（infrastructure configuration）
• SOAのための問題測定（problem determination for SOAs）
• Information Technology Infrastructure Libraryのプロセス（ITIL processes）
• ライブシステムでの変更管理（change management in live systems）
• サービスの移動（service migration）
• サービスのモビリティ（service mobility）
• SOAのランタイム（SOA Runtime）
• 仲介・変形・ルーティングためのESB（Enterprise service bus for mediation, transformation and routing）
• 実行時の開発とサービスの登録（runtime development and service registries）
• レガシーアプリケーションの統合（integration of legacy applications）
• SOAアプリケーションと実行時の再コンフィグレーション（SOA adaptation and runtime reconfiguration）
• データアクセス・データ統合・スケーラビリティ・トポロジ・最適化のための情報サービス（information services for data access and data integration, scalability, topology and optimization）
• サービス指向のミドルウェア（service-oriented middleware）
• ポリシーベースの設定と計算負荷管理（policy based configuration and workload management）
• QoS（Quality of Service）
• 信頼性の高いサービス指向コンピューティング（Reliable service-oriented computing）
• サービス指向コンピューティングにおけるセキュリティとプライバシー（security and privacy in service-oriented computing）
• SLAとポリシー仕様と制定（SLA and policy specification and enactment）
• QoSネゴシエーション（QoS negotiation）
• サービスレベルの自律的な管理（autonomic management of service levels）
• 経験的な学習とQoSのベンチマーキング（empirical studies and benchmarking of QoS）
• SoAにおける性能と信頼性予測（performance and dependability prediction in SOA）
• サービスアプリケーション（Service Application (Grid, E-science, Government, etc.)）
• 下部構造資源の管理のためのサービス・アーキテクチャ（Services and architectures for management of infrastructural resources）
• データ・計算に集中したアプリケーション（data- and compute-intensive applications）
• ジョブスケジューリングのための実行と資源割り当てサービス（execution and resource allocation services for job scheduling）
• 複数資源管理の連携のためのプロトコル（protocols for coordination across multiple resource managers）
• ビジネス価値ベースの割り当て（business-value based allocation）
• センサーと作動装置情報の獲得と散布（acquisition and dissemination of sensor and actuator information）
• プロトタイプシステムとツールキット（prototype systems and toolkits）
• サービスのビジネス・経済的側面（Business and Economical Aspects of Services）
• サービスとその展望のためのビジネス価値の見積もり（business value estimation for services and service landscapes）
• サービスの移行に関して（in connection with service migration）
• サービスの切断操作（disconnected operation of services）
• モバイルサービスの発見とアクセス（discovery of and access to mobile services）
• サービスネットワークの社会的側面（social aspects of service networks）
• 仮想的な企業や組織の生成・管理のための革新的な戦略（innovative strategies for creation and management of virtual enterprises and organizations）

「サービス」という単語が頻繁に登場しています。
SOAにおけるサービス（人間にとって意味のある処理の最小単位）と同義でしょうか？

今までの自分の研究分野とは少し違った学会なので、こんな研究もあるのか！と少しびっくりした感じです。
自分にとって新しい分野に積極的に出て行くことができたらな、と思います。

「BPEL4People」について知る必要があったので、少し調べてみました。

BPEL4Peopleとは

BPEL4Peopleとは、「BPEL for People」、つまり人間のためのBPELのことを指します。

BPELは本来、SOAの概念を実現するためにWebサービスを連携させて一つのシステムを構築する際の、Webサービスの連携フローを記述するために用いられるXMLベースの言語です。

しかし、多くのシステムの稼働時では、人が参加して作業を実行したり確認したりすることが多くなっており、Webサービス同士の連携のみ記述できるBPELではシステムの動作・仕様を正確に表現することが難しくなってきたようです。

そこで、人の行動・アクティビティもWebサービスと同じようにサービスとして統一的に記述することができる、BPEL4Peopleが開発されました。
人の行動をサービスとみなし、それらを含めたWebサービス同士の連携を記述可能とすることで、より詳細、正確なSOAに基づいたシステムが構築可能になるようです。

まとめ

人の行動もサービスとして統一的に記述するというBPEL4Peopleのアイデアに非常に関心を持ちました。

イレギュラーな行動をする可能性がある人をサービスとみなすことをは、非常に難しいことだと思います。
しかし、これが実現されると、世界でもっとも知的なサービス（人をサービスとみなしたもの）を既に存在するWebサービスと連携して利用することが出来るようになります。

これはすごい。
実用化例はあるんでしょうか？気になるところです。

自分の研究でも利用したいと思うので、下記の仕様書をより詳しく読んでみたいと思います。

• WS-BPEL Extension for People

参考文献

• ITベンダーら6社、SOA環境でのBPMを拡張する「BPEL4People」仕様発表 | エンタープライズ | マイコミジャーナル
• dev2dev： BPEL4People
• InfoQ: OASIS入りを目指すBPEL4PeopleとWS-HumanTask

「SOA」という言葉について知る必要が出てきたので、少しだけ調べてみました。

SOAとは

SOAとは、システム全体を「サービス」と呼ばれる部品を組み合わせることによって構築しようという手法、およびシステムアーキテクチャのことを指します。

部品を組み合わせてシステムを構築する手法は、オブジェクト指向などが従来にも存在していました。
それらの従来手法とSOAの違いは、組み合わせる部品（SOAにおけるサービス）の定義にあります。

SOAにおけるサービスは、実際に人間にとって意味のある単位を最小単位としています。
「人間にとって意味のある」というのは曖昧な表現ですが、しばしば業務上の処理単位を示しているようです。
（注文受付、在庫確認、発注処理など）

つまりSOAとは、人間にとって意味のある業務上の処理を単位としてサービスを定義し、それらを組み合わせることで一つの大きなシステムを作り上げることのことを指すのでしょうか。

SOAにおけるサービスは、グローバルに公開され、組織外における利用も想定されているため、標準的な技術によって実現、呼び出し可能であることが必要です。
サービスの呼び出し方法・インタフェースとして、しばしばWebサービスが利用されるみたい。
Webサービスは、XML、SOAP、WSDL、UDDIなどの標準的な技術によって構成されるので、SOAのサービスが満たすべき条件はクリアしていますね。
サービスの処理部分は何で実装されていても（Java or .Net or その他）いいようです。

また、複数のサービスを連携して一つのシステムを作り上げる必要があるため、それらの連携を記述する方法も標準化されている必要があります。
連携手順の記述言語としては、BPELと呼ばれるXMLベースの言語が用いられるみたい。
BPELは、BPMNという表記法によって図として作成することができ、視覚的に簡単に作成可能だとか。

まとめ

少し勉強した感じですが、すごく便利そうな概念ですね。
実際に世の中にSOAの考え方で構築されたシステムってどのくらい稼働しているんだろう。

あと、業務システムだけじゃなく、たとえば家電機器の連携に使ったりしても面白いんじゃないかと思いました。
既に研究されているような気もしますが。

新しいことを勉強するのってすごく楽しいですね。
これからも色々勉強したことをメモしていきまーす。

参考文献

• サービス指向アーキテクチャ – Wikipedia
• ＠IT情報マネジメント用語事典 [SOA (service-oriented architecture)]
• IT用語辞典 e-Words ： SOAとは 【サービス指向アーキテクチャ】 (Service Oriented Architecture) ─ 意味・解説
• IBM WSDD | SOA入門 - Japan

8月に行われる博士課程入学試験の参考書を入手しました。
「情報学基礎」という科目の参考書です。

参考書として指定されているのは以下の2冊です。

やさしいコンピュータ科学 (Ascii books)
	Alan W. Biermann 和田 英一 ASCII 1993-06 売り上げランキング : 93388 おすすめ平均 やさしくて面白い プログラミングの入門に やさしい？？コンピューター科学 Amazonで詳しく見る by G-Tools

情報科学の基礎理論 (21世紀を指向した電子・通信・情報カリキュラムシリーズ)
	上林 弥彦 昭晃堂 1997-05 売り上げランキング : 465044 Amazonで詳しく見る by G-Tools

「やさしいコンピュータ科学」のプログラミング言語入門の項で使用されている言語は「Pascal」です。
実際にさわったことはないので、少し勉強する必要があるかもしれません。

勉強がんばるぞー！

「ソフトウェアエージェント」という言葉について知っておく必要が出てきたので、Wikipediaで簡単に調べてみました。
ソフトウェアエージェント - Wikipedia

ソフトウェアエージェントとは、ユーザとユーザ、ユーザとソフトウェア、ソフトウェアとソフトウェアの間で仲介的な役割を果たすソフトウェアを示す言葉だそうです。

ソフトウェアエージェントの定義は人によってまちまちみたいなのですが、その中でも共通する要素として、以下が挙げられるみたい。

• 永続性

  ソフトウェアエージェントは常に起動された状態で、何かの処理を行う時期を自分自身で判断します。

• 自律性

  ソフトウェアエージェントは、種々の判断・行動を人間の手を借りることなく実行することができます。

• 社会性

  ソフトウェアエージェントは、ほかのエージェントやソフトウェアと協力し、一つのタスクを協調して遂行することができます。

• 反応性

  ソフトウェアエージェントは、自分の周りの環境を検知することが可能で、環境の変化にも柔軟に対応可能です。

上の4項目をみると、永続性・自律性を満たすソフトウェアは結構ありふれた存在のように感じます。
一方、社会性・反応性を十分に満たしているソフトウェアはあまり無い感じがするので、ソフトウェアエージェントという概念を説明するために重要な概念かもしれません。

ソフトウェアエージェントから派生する概念がいくつかあるみたいなんですが、ここでは4つだけ紹介します。

• 知的エージェント

  タスクの実行結果をよりよいものにするために、個々のエージェントが学習したり推論したりします。
  要は人工知能のようなものを備えたエージェントのことを指すのでしょうか？
  

• 自律エージェント

  ある目標を達成するための方法を、自分で考え出し、さらにその方法を実際に利用できるエージェントを指すみたいです（人間の手助けなしで）。
  エージェントが学習できる必要はあるはずなので、知的エージェントと重複する部分があるのかもしれません。

• マルチエージェント

  エージェント単体では目的を達成できないのですが、ほかのエージェントと協調することで目的を達成可能とするエージェントを指すみたいです。
  実装しようとすれば、サーバクライアントシステムではなくて、P2Pシステムになる感じ？
  マルチエージェントシステムを実現するためのフレームワークとしてGNUBrainというものがあるそうです（リンク先は現在PHPのエラーが出ているため閲覧不可orz）。

• モバイルエージェント

  実行環境（コンテキスト？）とともにコンピュータからコンピュータへと移動し、移動先のコンピュータでも動作することができるエージェントを指すみたいです。
  まさに移動するソフトウェア。
  モバイルエージェントを利用したP2PプラットフォームとしてPIAXがあります。

個人的には、マルチエージェントとモバイルエージェント、あるいはそれらを組み合わせたようなシステムに非常に興味があります。
どうやら「マルチモバイルエージェント」という言葉があるみたい。
今度調べます。

今回は完全にWikipedia情報を鵜呑みにしてしまいましたが、今後は論文も少しずつ読んでいって、エージェントに関する理解を深めていきたいと思います。
自分の知らないことを調べたり勉強したりするのっておもしろいですね！

博士課程に進学したら研究したいこと、というか研究計画書を考えなければいけない状況になってきました。

僕は現在、利用可能なネットワーク・コンピュータ環境が異なる地域間においてWebコミュニケーションを行う場合の問題を解決するための研究を行っています。

利用可能なネットワークの帯域幅が狭い地域の人々は、インターネットからファイルを取得するのに比較的時間がかかってしまいます。
その問題をP2Pネットワーク技術により解決したいと考えています。

回線速度が遅い地域のファイル取得時間を、できるだけ速い地域の取得時間に近づける「インフラ」（と呼んでいいのかは微妙だけど・・）を作ることを修士論文研究の目標としています。

博士課程は、異文化コラボレーションを研究している、石田・松原研究室に進学したいと考えています。

「コラボレーション」とは「コミュニケーション」とは別のことを指している言葉で、コミュニケーションによって何かを生み出すための協調作業を行うことです。
石田・松原研究室では、異なる文化を持つ人々がコラボレーションを行う場合に生じる種々の問題を明らかにして解決する取り組みが行われているようです。

もし進学できたら、僕は（「異文化」の本質からは少し離れてしまうかもしれませんが）異文化コラボレーションを行う際のネットワークにおける問題点を明らか、解決するような研究に携わりたいと思っています。
インターネットガバナンスや情報格差などの問題点が存在する中で、どのようにすれば異文化・異地域間コラボレーションを上手く行えるのか、について考えていきたいです。

自分が好きなネットワークの技術を使って、異文化間・異地域間のコミュニケーション・コラボレーション問題を解決するための仕組み・システム作りに携われたら、すごく楽しそうですよね。

非常に大まかではありますが、現時点で考えている博士課程での研究内容はこんな感じです。
もっともっと具体的にする必要がありますし、もしかしたら根本からひっくり返る可能性もあります。

例えば、複数のエージェントが協調して回線速度の遅い地域に全力でできる限り速くファイルを送り届けてくれるエージェントシステムを作るとか、そんなことが今日ボケッとしていたときに思い浮かんだんですが、研究としてはどうなんだろう・・・--;

それでも、今考えていることをどこかにアウトプットしておきたかったので書いてみました。
もっと研究頑張らないと・・！

僕は今、大学院の研究室でM2の学生として研究をさせていただいています。

最近ふと思ったのですが、大学（または大学院）の研究室の役割って何でしょう？

研究としての成果を出すこと？
学生を教育すること？
その両方？

答えとしては「両方」というのが適切なのでしょうか？

でも、両方っていうのはもしかしたらなかなかしんどいことかもしれません。
そうなったときに、どっちを優先するものなんでしょう。

僕個人の意見としては、大学や大学院はあくまでも教育機関であると思うので、やっぱり「教育すること」が最大の目的なんじゃないのかな？と思ったりします。
もちろん、社会に最も近い教育機関として、社会で最も必要とされる「成果」を求めることも重要なんだとは思いますが、「過程」も同じくらい、あるいはそれ以上に重要だと思います。

少し色々なことの効率が落ちたとしても、長い目でみればよかった、というようにするのが良いんじゃないかなぁ？？
現段階でもっとも効率のよいことをするよりも、色々な人に活躍の場を与えて将来的に効率が良くなるようにするのが良いと思います。

話は少しずれてしまいますが、最近小学校の先生で、生徒に「お前はどうしようもないくらい絵が下手だなぁ」と言う先生がいるようです。
ほんと、何を考えて教師をしているんだろうと思います。
子どもの芽を摘むようなことを教師がして、どうするんだろう。

小学生と大学生（院生）の違いはあれど、教育機関で学ぶ身としては基本的には同じような気がするんです。
できないからといって切り捨てるんじゃなくて、できないならできるようになるために一緒に頑張って考えることが必要なのではないでしょうか？

でも、やっぱり僕自身の経験が浅すぎるので何が正しいのかわからないです。
何も知らないのに、いろいろ書いても説得力ないですよね。

でも、今回はとりあえず今思ったことを書き留める意味で書いてみました。

教育の分野についても勉強してみたいと思います。

論文の「評価」項目に書く内容を考えると、よく悩んでしまうことがあります。

どうやら「評価」項目の書き方にもいくつかのパターンがあるみたいなのでまとめてみます。

1. 従来方式（システム）と提案方式の評価結果を比較し、良くなったこと、あるいは、悪くなったことについて述べる
2. 比較すべき従来方式が無い場合は、何らかのしっかりとした根拠により達成したい数値目標を定め、その値と提案方式のデータを比較する
3. 達成したい数値目標を論理的に導き出せない場合は、提案方式を使おうかなと考えている人が、データを見て使うか否かを判断できるように書く
4. 具体的なデータを取得できない場合は、考えられる複数の状況に従来方式と提案システムを適用した時に、どちらの方式の方が適しているのか、ということについて論理的に述べる
5. 比較すべき従来方式もなく、データも取れない場合は・・・・・わかんないです

こんな感じでしょうか？

評価の書き方について悩んでしまった場合、いったん落ち着いて上のパターンのどれかに当てはめて書くことはできないか、考えてみるのも良いかもしれません。

僕は、研究室に配属されてから今まで、ネットワークを介した組み込み機器連携のためのミドルウェアに関する研究を行ってきました。
いわゆる、ホームネットワークという分野の研究です。

この間、「機器連携」という言葉は実際にはどういうことを指しているのか、ということについて考えたのでエントリーとして書こうと思います。

僕は、未定義機器（現在は世の中に存在していない、仕様が未知の機器）が、既存機器のみで構築されたネットワークに新たに接続された場合においても、機器連携を実現可能にするミドルウェアを、Jiniというミドルウェア技術を拡張することで提案しました。

僕が提案したミドルウェアは、機器の利用者は必ずGUIを利用してネットワークを介して機器を操作する、という制約を課すことで、既存機器が未定義機器に対応できるようにするものです。

でもゆくゆく考えると、GUIを利用して機器を操作することは「機器連携」とは呼ばないんじゃないか、そんな気がしてきました。

僕の考える「機器連携」は、人を介さない機器同士のインタラクションです。
少し例を挙げます。

ある家に、複数の音楽提供機器（オーディオコンポやPC、Musicサーバ）と複数のスピーカが存在し、それらがネットワーク（家庭内LANなど）で接続されていたとします。
そこの家の住人が、スピーカから出力される音の音質が気に入らず、ネットワークに繋げるだけで家中のスピーカの音質を向上させる小さな機器を買ってきました。
家について、買ってきた小さな機器を家のネットワークに接続するとあら不思議。
何の設定作業をすることなく、家中のスピーカから出力される音の音質が向上されました。

本当は、上に挙げたようなことが「機器連携」なのではないかと思うのです。

僕の提案したミドルウェアは、人がGUIを利用して操作するためコマンドを機器に対して送信しなければならない、という点で「機器連携」を実現できているとは言えず、あくまで「機器操作」のためのミドルウェアなのだと思います。

言葉の定義の問題なのかもしれませんが、これはホームネットワークに用いるミドルウェアを考える上でとても重要なことだと思います。

あー、もっと早く気づいていればよかったなーorz

5/6から5/8にカナダのハリファックスという場所で行われた、「CNSR2008（Conference on Communication Networks and Services Research）」という国際学会で発表してきました。

僕にとっては初めての国際学会。
英語で上手く発表できるかどうか不安でしたが、今の自分の英語能力を考えるとベストを尽くせたと思います。
質問にもなんとか答えることが出来ました。

発表内容は以下のページで見ることが出来ます。
CNSR2008 — NISLab HOME

卒業研究として行っていた研究の内容について発表させていただきました。

質問では、
「あなたの提案システムと、W3Cで標準化が行われているWebサービスの発見方式は同じもの？」
という質問をチェアの先生にしていただきました。

僕はその質問に対して、
「私はW3CのWebサービス発見方式についてはよく知りません。ですが、それと私の提案方式は違うものです」
と答えました。
（実際はこんなに綺麗には答えられなかったけど・・）

頂いた質問は暗に、
「個々のミドルウェアでサービスの発見方式や未定義サービスへの対応方法などを考えるよりも、すでに標準化が行われているWebサービスの技術を使った仕組みを考えた方がいいんじゃない？」
という意味を含んでいるのかなと思いました。

このことについては、後日改めてエントリーとして書きたいと考えています。

英語を使ったプレゼンテーションを通して、度胸がついたのはもちろんのこと、英語を勉強することの必要性を実感できたなど、様々なためになる経験をすることが出来ました。
まだ、国際学会での発表を経験していない大学院生・学部生は、積極的に研究室の外の世界に飛び出して、色々なことを学んでいけたらいいのではないかと思います。

今回の発表で、卒業研究から大分引っ張っていたテーマも一段落。

あとは、修論のテーマを進めるべく突っ走ります！

平成19年度の博士課程平均競争倍率が0.9倍と、過去15年間で最低の水準を記録したようです。

世界に伍（ご）していくための高度研究・教育を担う人材を育成する「大学院博士課程」の平均競争倍率が平成１９年度、０.９倍を割り込み、過去１５年間で最低を記録、関西の有名国立大の中には、定員を充足するために４月に入って追加募集を実施した大学もあるなど、"博士離れ"がより深刻になっていることが１２日、分かった。
博士離れ深刻　競争倍率０.９倍割り込む - MSN産経ニュース

文部科学省が推進した「大学院重点化計画」により、日本における博士課程進学者が一時期は増加していたようです。
しかし一方、博士課程卒業後の就職先は増えることはなく、博士課程に進んでからの自分の将来に不安を感じる人が増加。
そのため、博士課程を志望する人が少なくなってきているようです。

以前、以下のようなニュースがありました。

　全国で初めて秋田県教委が実施した博士号取得者対象の特別選考で合格した理工系大学研究員６人が１日、県立高校教員に採用される。選考は予想を大きく上回る１０倍の難関だった。地方の教員試験への博士殺到には、「末は博士か大臣か」と言われた時代からは想像もつかない深刻な理由があった。（宮原啓彰）
「博士募集」に応募殺到　秋田県教委が教員採用 - MSN産経ニュース

それだけ、博士号を取得した人達の就職先が少ない、というこのなのでしょう。
博士号を取得した人は、修士卒や学部卒の人達と比べて、より高い専門性を身につけています。
それなのに就職先が少ないのは、多くの企業は専門性よりも汎用性を持っている人材を求めているからだそうです。

僕は、現在修士2回生で、来年度は博士課程への進学を決めています。
（入試に合格しなければなりませんんが・・・）

このようなニュースを見て、正直不安な気持ちにはなりました。
結局は、「自分は何をしたいのか？」「何故博士課程に進むのか？」ということを考えて理解し、その目的を実現するために頑張って研究・勉強することが重要で、将来の就職が不安であってもそれはあまり関係のないことなんじゃないかと個人的には思ってます。
（もちろん、食べていけるだけのお金は稼がないといけないのですが）

日本全体としての技術力を向上させたり、世界に向けて次々とイノベイティブなものを 送り出したりするために、やはり博士号取得者は増えていくべきなんじゃないでしょうか？
そのためにも、博士号取得者が活躍できる場を生み出す取り組みが必要なのではないかと思います。

3月29日（土曜日）に京都のキャンパスプラザで行われた「第2回関西P2P勉強会」に参加してきました。

当初は13:30から17:30までの予定だったのですが、発表が押しに押しまくって、結局終わったのは20:00過ぎになったようです。
僕は、後に予定があったため最後の発表の途中で退席させていただきました。

以下、発表のまとめ・感想です。（敬称略）

構造化オーバレイ Skip Graph と PIAX における活用」 (株) BBR CTO　吉田 幹

前半は、世の中では「構造化オーバレイといえばDHTでしょ」という風潮がはびこっていますが、他にも「Skip Graph」という良い構造化オーバレイの種類があるんですよ、というお話。

Skip Graphは、世界的に認知度が低いものの、検索がlog nのオーダーで可能、範囲検索が可能、等といった優れた特徴を持っているみたい。

でも何故世界的に認知度が低いのだろう？と疑問を持ったので質問させていただいたところ、理由は大きく2つあるみたい。

• 元の論文の内容がひどく難しい。理解しにくい。
• 世の中にDHT信者が多い

後半はP2Pエージェントプラットフォーム「PIAX」のマルチオーバーレイ機構についてのお話。

PIAXでは、アプリケーションからの様々な探索要求に応えるため、複数のオーバレイネットワークをプラグイン化し、クエリのパターンによって動的に切り替えることができるみたい。

プラグイン化したオーバレイネットワークには、緯度経度による範囲検索が可能な「LL-Net」や、みなさんご存じ「DHT」などがあるようです。
また、それらのオーバレイネットワークは全て「Skip Graph」の上に実装されているみたい。

ノードの参加・離脱に関して排他制御が必要だという弱点があるみたいですが、「Skip Graphすごーい！」と素直に思いました。

「幾何学的な接続経路を持つP2Pドロネーネットワークについて」 関西大学　奥 智照

各ノードの座標情報（緯度経度でいいのかな？）を使って、ドロネー図を構築し、それをそのまま、ノード間のリンク情報として利用してしまおうというお話。

ドロネーネットワークは、ノードの離脱による影響が局所的な範囲に収まる、各ノードの次数は必ず6以下になる、といった特徴を持っているようです。

また、LL-Netよりもノードの位置情報により強く依存したP2Pネットワークのトポロジ構成手法、という印象を受けました。

実際にドロネー図を用いて構築したP2Pネットワークを使って何ができるのか、といったことにあまり触れられなかったのが少し残念。

現状は、何かの通信インフラを各ノードが利用するという前提でのお話でしたが、アドホックネットワークに適用すると面白いことができるんじゃないかな、と思いました。

2つ以上のノードが座標的に重なったときにも正しく動作するのか？、などの質問事項が浮かびましたが、結局質問できませんでした。

「Inside Bamboo DHT」大阪市立大学　藤田昭人

分散ハッシュテーブル実装のひとつである「Bamboo DHT」についてのお話。

といっても話の主旨は、JavaでかかれているBamboo DHTを諸事情によりC++に力業で翻訳しました（所要時間1年）、という面白い発表でした。

翻訳をしていく過程で、藤田さんはC++とJavaの知識がかなりついたそうです。

しかし、翻訳過程でC++とJavaの知識をつけていったこと、あまりにも逐次的に翻訳しすぎたこと、等が原因で、現在メモリリークの問題が大変なことになってしまっているそうです。

質疑の時間で、どのようにメモリリークを解決するか、等についてかなり白熱したコアな議論が行われていました。
Javaだとガベッジコレクションありきでかかれているので、参照だらけになっていることや、C++でfreeするときに参照されているオブジェクトを消してしまうかもしれない、といったことがネックになっているみたい。
非常に興味深かったです。

「Network Aware OverlayとNetwork Coordinate」 同志社大学　木浦正博

同じ大学の木浦君の発表。

主に、オーバレイ上で実ネットワークを考慮するための諸技術に関するトピック紹介、のようなお話でした。

Network-Aware Overlaysというのが、オーバレイ上で実ネットワークを考慮する試みのことを指すらしい。
こうすることで、ネットワークトラフィックが局所化できるようです。

ネットワークの距離計測にはおもに遅延時間を用いるみたい。
また、すべてのノード間の遅延時間を計っていては効率が悪いので、すでに距離が解っているノード情報を用いて他のノードとの距離を「予測」する方式が提案されているそうです。

その代表格である「Vivaldi」という技術の詳細についても説明されていました。

僕自身の研究で、オーバレイ上で実ネットワークを考慮するための技術（最も早くファイルがダウンロードできるノードを探したい）が必要なので、発表内容ついてに非常に関心を持ちました。

ただ、今回紹介されていた技術は、「ネットワークトラフィックを局所化」するための試みで、「ファイルをできるだけ早くダウンロードできるノードを探す」ための試みではなかったようです。
もしかしたら、ノード間の距離の尺度として遅延時間以外のもの（利用可能帯域、パケットロス、ジッターなど）も考慮されているのかもしれませんが。。

後者の技術について何かご存じであればお聞きしたいと思ったのですが、結局質問出来ませんでした。

「P2P手法によるインターネットノードの階層的クラスタリング」 大阪市立大学　上田達也

先の発表でもあったNetwork-Awareオーバレイの技術を使って、ノードをクラスタリングしましょう、というお話。

後の予定もあったため、途中で退出してしまいました。
申し訳ありません。

タイトルと同名の論文が、情報処理学会の論文誌に掲載されているようです。
今度読みます。

まとめ

全体的にみて、かなり濃い内容の勉強会でした。

質疑の時間も、前の方におられた方々が話の本質を突くすばらしい質問をされていて、とても有意義な時間を過ごすことができました。
技術の深いところに対する突っ込みは、聞いててとても勉強になりますし、とても興奮しました。

個人的にも、知らなかった話題・ネタを仕入れることができましたので、とても満足。

あえて苦言を言わせていただくとするなら、「時間押しすぎ！」ということでしょうか・・
時間はルーズな感じで行くなら、その旨をプログラムに記載する。
そうでないのなら、主催者権限で発表or質疑を終わらせる。
のようなことが考えられてたら、なお良かったかも
（と、5分も遅刻した時間に対してルーズな僕が行ってみる:p

なにはともあれ、本当に勉強になりました。
主催者・発表者の皆様、おつかれさまでした＆ありがとうございました。

次もあれば是非参加させていただきたいと思います！

「研究者は何のために論文を書くんだろう？」
と少し疑問に思ったので書いてみようと思います。

きっかけは、下のエントリーと、研究室の先生からいただいたmixiのコメントです。
知の開国：大学の若手研究者ができる４つのこと - tatemuraの日記

今までの僕の短い人生経験の中で思いつく、研究者が論文を書く理由を箇条書きにしてみます。

• 世間に評価されるため

  「俺はこんなすごい技術を発明したんだぜ！俺ってすごいだろ！」という人。（まだ会ったこと無い）

• 世の中の役に立つため

  「私の考えた方法を使うと、世の中がこんなによくなるんです！」という人。

• 自己満足のため

  「あなたにノーベル賞を差し上げます！」「いりません」という人。

• 研究者として生き残るため

  「業績＝通った論文の本数なんです！」という人。（日本では論文数偏向主義というのがあるらしい）

僕としては、将来「世の中の役に立つため」に論文を書いていきたいな。

とはいえ、「研究者として生き残るため」にも書いていかなければならないんでしょうけど。

両方を満たす論文を書いていけばいいのかな。

「論文の章立て」フレームワークがあればこんな感じでしょうか？

1. はじめに

   研究の背景や目的、論文の構成について述べる。
   「何らかの技術の問題を解決する」ことが目的である事が多い。

2. hogehogeの概要

   研究の目的に関わる技術の概要を述べる。
   説明は研究の目的と本質的に関わる部分（後ろで必要となる部分）のみにとどめる。

3. hogehogeの問題点

   研究として解決したい問題点についてを述べる。
   自分がどんな問題を解決したいのかをできるだけ明確に書く。

4. 提案手法

   問題を解決するために提案する方式について述べる。
   自分のオリジナリティを最も発揮しやすい場所なので、しっかり詳しく書く。

5. 実装

   提案手法の有効性を確認するために実装したシステムについて述べる。
   本質的ではないが工夫した部分（システムのアーキテクチャなど）はここに書く。
   

6. 評価

   提案手法の有効性を証明するために行った評価について述べる。
   ここでは、評価結果を淡々と書くのみにする。
   また、評価環境はできるだけ詳しく（読んだ人が再現できるように）書く。

7. 考察

   評価結果を受けた考察を述べる。
   結果が良くなかったとしても今後の課題につながるのでとりあえず書く

8. 関連研究

   同じ問題を解決しようとしている他の研究について述べる。
   自分の提案手法と比較してどうなのか、について書けるとよい。

9. まとめと今後の課題

   背景から考察までを簡潔にまとめる。

   今後の課題には、提案手法の改善するための具体的手法を書く。

まとめ

こんな感じでしょうか？

関連研究については「はじめに」の直後にある場合も結構ありますね！

こうやって考えてみると、一年もあれば卒論きちんと書けそうな感じがするのになぁ・・・

研究に関するメモ。

評価として適切なデータが取れないからといって、そのために提案方式を変えるのは非常に良くないアプローチみたいです。

論文の論理的な流れを逆流するようなアプローチをとってはいけません。 論文の「はじめに」からの流れが台無しになってしまいます。

それをするぐらいなら、「何故適切なデータが取れないのか」「何故二つの間に差が出ないのか」などを述べた方が良いそうです。

今日Bookmarkしたページの紹介です。

研究テーマを探している学生のときに考えた事 | Lifehacking.jp

研究テーマをなかなか見つける事が出来ない人へのアドバイスが書かれた記事です。

著者が昔行っていた研究テーマ発見手法についての説明があります。

僕の周りにも「研究テーマがない」「見つからない」「自分で見つけることが出来ない」と言っている人が何人かいますが、その人たちに読ませてあげたいと思いました。

特に以下の部分。

なかには、あきらかに自分の情報不足を自分の能力不足と勘違いしている場合もあって、惜しいところで空回りしている場合も見受けます。Google を使うのは、同じところで回転している自由度のない０次元の自分に、興味のベクトルという新たな次元を与えて、視座を得るためでもあるのです。

考えが煮詰まったからといって自分を見限るのはとてももったいない事です。煮詰まったと感じたら、違う方法で、あるいは違う視点から物事と向き合うことが大事ですね！

「メールを読むだけでルーターが設定変更される」、驚異の新攻撃出現：ITpro

自分宛に送られてきたメールを読むだけでルータの設定が変更されてしまう、という攻撃の紹介記事。

メールに含まれるHTML・JavaScriptコードが読み込まれると、ブロードバンドルータのDNS設定が書き換えられ、特定のサイトへのアクセスが攻撃者のサーバに転送されてしまうという攻撃です。

これは攻撃する人も考えましたねー。

対策としては、ブロードバンドルータのログインパスワードをデフォルトの状態から変更する、あるいはHTMLメール自体読まない、などがあると思います。

用心用心！

今日、自分が研究として実現したいことと、ほぼ同じことをやろうとしている団体があることを知りました。
これから頑張ろう！と意気込んでいた矢先に。。。

とりあえず今からやることは、その団体のやろうとしていることについて調べること。
調べた上で、自分のアイデアでオリジナリティを出せる場所を見いだすこと。
最後にその団体にメールか何かで連絡して、お話を聞くこと。

できれば自分の手で実現させたいことだけど、他の誰かがやった方が上手くいくのであれば、それは誰かに任せた方がいいかと思ってます。
自分で研究する、っていうのは目的ではなくて、あくまでも実現させたいことを実現させることが目的。
一番いいのは、その団体に入れてもらうことですかね（笑

今日は研究室の月例発表会。 今回は僕も発表してきました。 新しい研究テーマ。 苦手な質疑応答も、以前と比べたら、まぁ少しはマシになったかな？？

今は明日朝からのアルバイトのため、東京のとあるホテルにいます。 打ち上げ参加したかったお；； ていうか、このホテルハンガーないしｗ どういうこと？？ｗ

--------------------------------------------------------------

以下、今とりあえず書きたい自分の気持ちを書きます。

一からレジュメを書いていくのは大変だったけど、とても楽しかった！ わくわく、ドキドキ、楽しい。 たぶん、ドラゴンボールの悟空がものすごく強い敵と戦う前の気持ちに似てるのかな？

もしかしたら、他の人がすでに僕がやりたいことを実現してしまっているかもしれない。 もしかしたら、自分は検討違いのことを言っているのかもしれない。 そんな不安も無いと言えば嘘になるけど、とりあえずは気にせずに前に進むことが大事なんじゃないかという気がしてきました（ちゃんと調査はしますけどね）。 研究が成功しても、ダメになっても、それはきっと前に進んでるということ。

もちろん、どこかに自分のオリジナリティを出さないと研究として成立しないことは理解してます。 研究の長期的な計画を立てることが重要なこともわかってます。 でも多分、今自分がやっていることに誇りをもつこと、楽しいと思うことも同じくらい大事！

そう言う意味で考えると、僕は今とても充実しています！ 友達・研究・ボランティア・アルバイト・プライベート、すべて存在が今の僕を支えてくれてます。 本当にありがとうございます。 もちろん現状に満足するだけじゃなくて、常に前に・先に進み続けます！ いやなことがあってもくじけないぞ！ もっと広い世界に飛び出すぞ！ そして、新しい研究が実を結んでくれるといいな☆

P2Pネットワークのシミュレーションを行いたいので、どこかにいいシミュレータがないかな、最近探していました。今日見つけたのがPeerISimというP2Pシミュレータです

• PeerSim: A Peer-to-Peer Simulator

ソース・バイナリは、次のページでダウンロードすることができます。

• SourceForge.net: peersim

PeerSimはJavaで実装されているP2Pシミュレータ。次の二つの要素で構成されているみたいです。

• cycle-based engine
• event-based engine

cycle-based engineとは、スケーラビリティ確保のためにトランスポートレイヤーの詳細を無視して、簡単な前提のもとシミュレーションを行うエンジンのようです。

event-based engineとは、トランスポートレイヤーのシミュレーションも行えるエンジンのようです。cycle-basedエンジンと比べて効率は落ちますが現実的なシミュレーションができるみたい。

オープンソースなので、誰でも利用することができ、かつソースコードも読むことができます。

まだ読んでいませんが、ドキュメントも充実してそうでいい感じ。さらに、PeerSimを使って評価したプロトコルのコードおよびコンフィギュレーションファイルもダウンロード可能です！

ちょっと面白そうなので試しに使ってみます。利用方法などはまた記事に書くと思います。

NS2は、既存のプロトコルや自ら開発したプロトコルをシミュレートできるソフトウェア。今回は研究のためNS2を利用する可能性が出てきたため、インストールの手順をメモします。

今回は手軽（？）利用できるようにするため、WIndowsXP + Cygwin環境上にNS2をインストールすることにします。前提として以下の作業を完了している必要があります。

• CygwinをWindowsXPにインストール - CreativeStyle
• Cygwinに基本的なパッケージをインストール - CreativeStyle

1. NS2のインストール

Cygwinを立ち上げて、以下のコマンドを入力しソースファイルをインターネットから取得します。

$ wget http://www.isi.edu/nsnam/dist/ns-allinone-2.30.tar.gz

次に、ダウンロードしたファイルを展開します。

$ tar zxvf ns-allinone-2.30.tar.gz

展開したディレクトリに移動します。

$ cd ns-allinone-2.30

インストールスクリプトを実行します。必要なパッケージがインストールされているかどうか確認してからインストールを自動で行ってくれます

$ ./install

2. 環境変数の設定

環境変数を追加するため、ユーザのホームディレクトリ（/home/○○）の.bashrcというファイルに以下を追記します。

export PATH=/home/○○/ns-allinone-2.30/bin:$PATH
export LD_LIBRARY_PATH=/home/○○/ns-allinone-2.30/otcl-1.12:/home/○○/ns-allinone-2.30/lib:$LD_LIBRARY_PATH
export TCL_LIBRARY=/home/○○/ns-allinone-2.30/tcl8.4.13/library

2. 動作確認

動作確認を行います。以下のコマンドを実行し、X Serverを起動します。初回起動時はWIndowsファイアフォールのプロンプトが出ますが「ブロックを解除する」を選択してください。以下同じです。

$ startx

するとターミナルが表示されるので、以下のコマンドを実行します。

$ ns ns-allinone-2.30/ns-2.30/tcl/ex/simple.tcl

コマンドを実行した結果、次のようなウィンドウが表示されたら成功です！再生ボタンを押してしばらくすると（結構何もない時間が長いからあせる・・・）パケットの動きがアニメーションで表示されます。右上の「つまみ」のようなものでシミュレーションの速度も調整できます。動いてちょっと感動・・・

以上でインストール完了です。さて、バリバリ使うぞーー！

PLRG（Power Law Random Graph）とは、P2Pネットワークにおけるトポロジの分類の一つ。

「モバイル環境における端末の位置情報に基づくP2Pネットワークの提案と評価」（金子雄， 福村真哉， 春本要， 下條真司， 西尾章治郎 - 電子情報通信学会データ工学ワークショップ (DEWS 2004) 論文集, 2004 ）によると、定義は以下のようなものだそうです。（記号「^」はべき乗を表す）

PLRG（Power Law Random Graph）ネットワークにおいて各ピアはPower Lawに基づく数だけ隣接ピアを持つ．ネットワーク上のピア j における隣接ピアの数を dj とするとし， dj の分布が次に示す関数 f ( dj ) に従うとき，そのネットワークはPower Lawに従うという．

f ( dj ) = j ^ β

ふむ・・・。わかったような、わからないような。

つまり、次に示すようなネットワークのいづれかを指すのでしょうか？

• 隣接ノード数が少ないノード→とても少ない＆隣接ノード数が多いノード→とても多い
• 隣接ノード数が少ないノード→とても多い&隣接ノード数が多いノード→とても少ない

なんとなく後者の方な気がするけど、どっちが正しいのかな？（どっちも正しかったり？）

複雑性理論という言葉が読んでいる論文に出てきました。Complexity Theory

Wikipediaには

計算複雑性理論（けいさんふくざつせいりろん、computational complexity theory）とは、計算機科学における計算理論の一分野であり、アルゴリズムのスケーラビリティや、特定の計算問題の解法の複雑性（計算問題の困難さ）などを数学的に扱う。

とあります。

少々読み進めていくと、

具体的には、計算複雑性理論は「あるアルゴリズムへの入力データの長さを増やしたとき、実行時間や必要な記憶量はどのように増えるか？」という問いに答える。

ということがわかりました。