まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

IBM Notes 9.0.1 の FP(Feature Pack) 8 がリリースされました。有効なサポート契約をお持ちであれば、以下の FixCentral サイトからダウンロードして適用いただくことが可能です:
http://www-01.ibm.com/support/docview.wss?uid=swg24037141


適用後にメニューから ヘルプ - IBM Notes について を実行すると、リリースバージョンが変更できていることが確認できます。自分の環境にも早速適用してみました:
2017030901


実は以前にこのブログの中で、「ノーツでワトソン」というエントリを紹介したことがありました(比較的アクセス数の多い、人気エントリの1つです):
http://dotnsf.blog.jp/archives/1062359514.html

↑この中でも触れているのですが、Watson API のセキュリティ仕様変更があり、JDK 1.8 未満の環境から Watson の REST API へ https リクエストを実行するとエラーが返されるようになってしまっていました(ノーツは JDK 1.6 を使っていたのでエラーが発生していました。上記エントリはその回避方法も含めて紹介しているものです)。

が、今回の 9.0.1 FP8 では、内蔵 JDK バージョンが 1.8 に変更される、という大きな変更が含まれていることになっています。これによって Watson API のセキュリティ要件を満たすことになるので上記エントリのような回避策も不要になることが期待できます。

というわけで、IBM Notes 9.0.1 FP8 の実際の JDK バージョンを確かめるためのプログラムを作って実行してみることにします。まずは Domino Designer で適当なデータベースアプリケーションを作り、その中に Java のエージェントを新規に作成します(エージェントの名称は FP8 としました):
2017030902


Java エージェントの中身を記述します:
2017030903


具体的には以下のようなコードを記述しています(初期状態の内容と比較して、青字部分を追記しています):
import java.util.Properties;

import lotus.domino.AgentBase;
import lotus.domino.AgentContext;
import lotus.domino.Session;

public class JavaAgent extends AgentBase {
  public void NotesMain() {

    try {
      Session session = getSession();
      AgentContext agentContext = session.getAgentContext();

      // (Your code goes here)
      Properties props = System.getProperties();
      props.list(System.out);
    } catch(Exception e) {
      e.printStackTrace();
    }
  }
}

↑システム内の全プロパティを取得して、標準出力(System.out)にプロパティ名とその値を表示する、という内容です。Java のバージョンもプロパティの1つなので、この出力結果の中に含まれているはずです。

このエージェントをメニューから実行できるよう、基本プロパティのトリガーはイベントで「アクションメニューの選択」、対象は「データベースの全ての文書」とした上で、このエージェントを保存します:
2017030904


では作成したエージェントを実行してみます。結果は標準出力に出されるので、あらかじめメニューのツールから、Java デバッグコンソールの表示 を選択して、出力画面を表示しておきます:
2017030905


改めてメニューから アクション - FP8 を実行します:
2017030906


するとエージェントの実行結果が Java デバッグコンソールに追加記載される様子が確認できます:
2017030907


画面を少しずつ下にスクロールしていくと、"java.version" というプロパティの値が "1.8.0" になっていることが確認できました。ちゃんと(?) 1.8 が使われているようです:
2017030908


 というわけで、IBM Notes 9.0.1 FP8 からは JRE/JDK 1.8 が使えるようになりました。これで Java プログラミング時に互換性を心配しながらコーディングする必要はなくなりました。


画像(特に写真)ファイルの中には、その写真を撮影した時の日時やカメラの種類、場所といった付属情報が含まれていることがあります。

それらのメタ情報を特定のフォーマットに従って画像に埋め込むことで、画像ファイルの中に、目に見えない形で撮影日時や撮影場所といった情報を含めて保存することができるようになります。

この「特定のフォーマット」のことを EXIF(EXchangable Image Format) と定義され、「イグジフ」などの略称で呼ばれています。

この Exif 情報をウェブブラウザから参照することもできます。多くはプラグインやアドオンなどの拡張機能として提供されています。私が個人的によく使っているのが、FireFox の Exif Viewer という拡張機能です:

https://addons.mozilla.org/ja/firefox/addon/exif-viewer/

2017030801


上記サイトから「Firefox へ追加」ボタンをクリックして FireFox にインストールし、FireFox を再起動すると有効になります。

使い方は簡単で、FireFox を利用中に Exif 情報を参照したい画像があったら、その画像の上で右クリックして「画像の EXIF データを表示」を選択、です(ちなみにこの画像は先日のベルサール秋葉原でのイベントで僕が撮影したものです):
2017030802


ウィンドウがポップアップして、選択した画像の Exif 情報が確認できます。画像に Exif 情報が含まれていた場合はこの中に表示されます。緯度(北緯 35.701442度)と経度(東経 139.770919度)が表示されていることがわかります:
2017030803


ちなみにこの場所を Google マップで開いてみると、見事にベルサール秋葉原・・・ではなく、少しズレがありますが(苦笑)、まあほぼ正解でした:
2017030804



つまり写真の中に位置などの情報が含まれていると、この方法で場所が特定できてしまうわけでもあります。まあ最近の SNS では「アップロードした画像の Exif は自動的に削除される」ような仕様になっているものが多いのですが、ネットに画像などをアップロードする際には気をつけましょう。


IBM ワトソンなどの各種コグニティブエンジンを使う際に、重要なのは学習データだと思っています。

要はコグニティブエンジンを使って問い合わせを行うわけですが、その問い合わせする前に何らかの学習をする必要があり、そこで何をどれだけ学習させたかによって問い合わせの精度が変わってくるからです。

で、先日こんなツイートをしました:
2017022601

https://twitter.com/dotnsf/status/834959690803007488


↑は、その学習データを何らかの方法で集める際に、(非同期処理で集めるのではなく)マルチスレッド処理がいいのではないか、と思ってつぶやいたのでした。このことをもう少し詳しく紹介しようと思います。なお、あくまで特定条件下での個人見解なので他の人の意見も聞いてみたいと思ってます。

やろうと思っているのは、大まかにはこんな内容です:
  1. あらかじめ用意したインターネット上の URL のリストから、その HTML を取得して学習データにしたい
  2. この「リスト」が大量にあるケースを想定する
  3. なお、リストの中には実在しない URL が存在している可能性がある(つまりリストそのものが間違っている可能性がある)
  4. また URL は実在しているのだが、ネットワーク障害や DNS の設定ミスなど何らかの原因でアクセスする際に非常に長い時間がかかる(長い時間がかかった結果、タイムアウトになったり成功したりする)場合もある

1と2はごく普通の条件ですよね。ここではインターネット上の URL のリストは配列変数で用意されているものとしましょう。配列から1つずつ URL を取り出して、その URL の HTML を取得する、という処理を施すことになります。

問題は3と4の条件です(でも現実的に想定すべき条件だと思ってます)。3は用意されたリストそのものが間違っているというケース、つまり与えられた URL は "Unknown Host" になったり、404 などのエラーが返ってくることを想定しないといけない、ということです。

また4は更にややこしい条件です。成功するかしないかではなく、こちらからは手が出せない箇所のなんらかの障害によって目的の URL へのアクセスに非常に時間がかかってしまうケースです。時間がかかった結果、目的の HTML が取得できればいいのですが、最終的にタイムアウトエラーが発生することもあり得る、というケースを想定する必要があります。


要するにこれらを想定したエラー対策が必要になるのですが、まずは3と4を無視して(エラーが発生しない前提で)普通にアルゴリズムを考えるとこんな感じになるでしょうか:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url );
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
}


↑の例ですと、getHTML 関数の中で実際に指定した URL にアクセスして HTML を取り出す、という処理をするものとします。そしてこの関数の中で3や4を原因とするエラーや時間がかかるといった現象が発生することを想定してみます。

3のケースは実は単純で、実在しない URL が指定された場合はこの関数の返り値を null などにして、null でなかった場合のみ処理を続ける、という判断を加えることで解決します:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url );
  if( html != null ){ //. 3の対策
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
  }
}


さて問題は 4 のケースです。3 のアルゴリズムを単純に(シーケンシャルに)実行した場合、特定の URL から HTML を取り出す処理に時間がかかってしまうような事態が発生すると、リストの途中で処理が先に進まなくなってしまう、ということになります。このようなケースを想定した上で効率よく処理を実行するにはどう改良すべきでしょうか?

1つの方法として考えたのが非同期処理です。上記のループ部分を非同期に処理して、リスト内の各 URL へのアクセスを非同期に行う、という方法です。アルゴリズムにするとこのような感じになるでしょうか:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url, function( err, html ){  //. getHTML を非同期に実行する
    if( err ){
      //. 3. のエラー処理
    }else{
//. 成功した場合
: : (取り出した HTML を使って学習処理を行う) : : } }); }
↑非同期ということで JavaScript っぽくしてみました

このように非同期に処理を行うことで、「各 URL の HTML を取得する」という命令を全て先に実行しておき、(成功にせよエラーにせよ)取得の処理が終わったらそれぞれの続きを行う、というロジックです。こうすることで 4 のような事態が発生しても、正常な URL に対する処理は邪魔されることなく先に終了し、時間のかかる処理だけが後から実行される、という一見きれいな形になります。

しかし、この方法にも問題点がありました。それは URL のリストが膨大だった場合です。上記のコードが非同期に実行されるとまず全て URL に対する HTML 取得のリクエストが発行されます。そしてその処理はシステムのメモリ量や TCP ソケット数上限を超えて実行されてしまう可能性があります。この部分はコーディングというよりもシステムのメモリ管理やソケット数管理などの厄介そうな処理を行う必要がでてきてしまいます。

で、冒頭のマルチスレッドです。上記の非同期で行っていた部分をマルチスレッドに書き換えることで、(スレッド生成間のスリープ時間を調整するなどの)ある程度のスケジュール調整をした上で同時に HTML を取得する処理を行うことができるようになります。例えばこんな感じです(ここは言語依存がありそうなので、Java 丸出しで記述しています):
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  //. 子スレッドを生成して、スレッドの中で取得処理を実行
  Download dl = new Download( url );
  Thread t = new Thread( t );
  t.start();

  try{
    Thread.sleep( 1000 ); //. 1秒待ってから次の URL を処理
  }catch( Exception e ){
  }
}


//. マルチスレッドで動くインスタンス
public class Download implements Runnable{
  private String url = "";
  public Download( String url ){
    this.url = url;
  }

  public void run(){
    html = getHTML( url );
    if( html != null ){
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
    }
  }
}

↑マルチスレッドなので Java 全開の記述法で

この方法であれば、各 URL に対する HTML の取得は別々のスレッドで行われるため、特定の URL で 4 のような遅延現象が発生しても、他の URL に対する処理がその遅延に巻き込まれることはありません。また、この例では1秒(1000ミリ秒)おきにスレッドを生成するようにしています。例えば1スレッドの処理が2秒程度かかるようなケースであっても、3つ目のスレッドが生成されたタイミングで最初のスレッドの処理は終了している可能性が高くなり、同時に実行されるスレッドの数がさほどは増えないようなアルゴリズムになっています。仮に 4 のようなケースが発生したとしても、そのスレッドだけはしばらくの間生き続けることになりますが、他のスレッドは生成しては処理されて消えてゆくという流れになるので、やはりシステムの限界を意識するような処理にはなりにくいアルゴリズムになっているのでした。


という所まで作っての「マルチスレッド処理が効率よい」という冒頭の結論に至ったわけでした。要するにこれなら深く考えずに作って動かしてもややこしい対応が必要になる心配が少ないかな、と。またマルチスレッド処理となると Java が得意とする処理ロジックであり、オッサン脳の出番が増えるかもしれないなあ、と感じたのでした。

このページのトップヘ