Posted by & filed under 勉強会.

このエントリーを含むはてなブックマークはてなブックマーク - JavaOne 2014 サンフランシスコ報告会 Tokyoの資料公開 このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - JavaOne 2014 サンフランシスコ報告会 Tokyoの資料公開 Share on Tumblr Digg This

JavaOne 2014 サンフランシスコ報告会 Tokyoで、JavaOneの報告をしてきました。

Java EEの報告と言いながら、そのパートは上妻さんに任せて、Project AvatarとSpring Frameworkについて話しました。
JavaOneに行けばOracle社以外の話も聞ける、という事実は大事かと思います。

まさか会場にアリエルの森本さんがいるとは思っていなかったので、少しドキドキしました。
これが仮に大谷さんであれば、アリエル社内で、虚実いりまじった話をされるところです。森本さんはまともな人なので安心です。

以下にプレゼンに使った資料を公開します。

JavaOne2014 サンフランシスコ報告会 Tokyo

井上誠一郎

アリエルネットワーク CTO

ワークスアプリケーションズ ゲストフェロー

JavaOne参加経験

  • 今年が4度目の参加(2010年、2012年、2013年、2014年)
  • 報告会発表は3度目

今年のJavaOne雑感

  • 人が多かった(ような気がする)
  • Oracle OpenWorldのキーノートでJavaOne登録者数9000人以上

今日のお題

  • Java EE (周辺事情)
  • Project Avatar
  • Spring Framework

CON3015: Java EE8

  • Java EE 8 Community Survey
  • 個人的にはMVCサポートに1票(Yes:60.8%は意外に低かった)

CON3015で無視されたサーベイ項目を拾ってみる

  • Should we define APIs to support use of JavaScript on the server (e.g.,Project Avatar)? Yes:42.4%
  • Should we investigate standardizing a client API for Thin Server Architecture? Yes:51.6%
  • Should we define a (new) standard templating framework? Yes:43.7%
  • Should we extract Facelets from JSF as the standard template engine for Java EE? Yes:36.8%
  • Is it time yet to standardize in NoSQL? Yes:40.7%
  • Should we standardize the use of java.util.logging by applications? Yes:70.1%
  • Should we define an embedded web container? Yes:71.7%
  • Should we define an embedded Java EE container? Yes:66.4%

CON6782: Apache TomEE, Java EE Web Profile, and More on Tomcat

  • 読み方は「トミー」
  • TomcatベースのJava EE実装
  • TomEE(Java EEのWebプロファイル)とTomEE(Fullプロファイル)
  • Tomitribe社 (http://www.tomitribe.com/)

Project Avatar

  • TSA(Thin Server Architecture)
  • サーバサイドJavaScript

Avatarの関連セッション

  • Project Avatar: Server-Side JavaScript on the JVM [CON5675]
  • JavaScript Across Tiers with Nashorn and Avatar.js [CON1815]
  • Avatar.js: Node Programming Model and JavaScript for the JVM [UGF9751]
  • Project Avatar: More Than Just Node.js on the JVM—Java EE Written in JavaScript [CON4091]
  • タイトルにAvatarはないが、検索でひっかかるセッションは他に4件

CON4091: Project Avatar: More Than Just Node.js on the JVM—Java EE Written in JavaScript

  • Avatar 2.0
  • TSAの言及はほとんどなくなり
  • Node.js互換アピールに完全シフト

avatar.js

  • Node.js on the JVM
  • ~95% Node.js API compatibility
  • many of the node-modules work

本家Node.jsとの違い

  • Nashornベース: Competes with Google V8
  • マルチスレッド
  • スレッドごとにイベントループ

Avatar2.0の新機能(Node.js互換性向上以外の話)

  • Avatar persistence (JPA(EclipseLink)、JDBC、NoSQL-APIをラップしたAPI)
  • JMS API (現状、JMSを使うにはWebLogicが必要)
  • Inter-thread communication (pub/subモデルのイベントバスAPI)

Avatar persistenceコード例

var avatar = require('org/glassfish/avatar');

var myDataProvider = new avatar.JPADataProvider({
  persistenceUnit: 'rest',
  createTables: true,
  entityType: 'Item'
});

myDataProvider.create(item, callback);
myDataProvider.get(key, callback);
myDataProvider.create(item).then(...);

イベントバスAPIコード例

var bus = avatar.application.bus;

bus.publish('echo', { x : 'x', y : 'y' });
bus.on('echo', function(body, msg) {
    avatar.log('Got message: ' + JSON.stringify(body));
});

Avatarのロードマップ(保障なし)

  • 2015年 Avatar Commercial Support
  • 公開プレゼン資料から引用
  • プレゼン時に聞いた記憶なし…

Avatarがライバル視するプロジェクト

  • RedHat nodyn.io
  • Vert.x
  • dynjs.org

Spring Framework関連のセッション

  • Spring 4TW! [CON3693]
  • The Spring BOF [BOF3868]
  • Running Your Spring Apps in the Cloud [CON4327]
  • REST Assured: Hypermedia APIs with Spring MVC [CON6071]
  • Migrating a JSF-Based Web Application from Spring 3 to Java EE 7 and CDI [CON3389]

CON3693: Spring 4TW!

Spring Framework4の特徴

  • embedded Webサーバ (Spring Boot)
  • message centric architecture
  • async processing

Spring Boot Actuator

  • ほとんどコードを書かなくても、Webアプリがモニタリング可能になる(REST API)
  • http://localhost:8080/health を叩いて死活監視
  • http://localhost:8080/info を叩くと管理ビーンのメソッドコール数の統計情報

まとめ

  • Java EEは進化を継続(ただしevolution)
  • AvatarはNode.js互換路線
  • Spring Frameworkに復活の印象(Spring Boot以降)

関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 勉強会.

このエントリーを含むはてなブックマークはてなブックマーク - JavaOne2014@サンフランシスコ レポート(パート1) このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - JavaOne2014@サンフランシスコ レポート(パート1) Share on Tumblr Digg This

JavaOne2014に参加するためサンフランシスコに行ってきました。

過去のレポート記事(関連記事をたどるトップ記事)のリンクは下記になります。

JavaOne参加は、ここ5年で4度目です。毎回サンフランシスコの同じような場所を徘徊するので街の様子も慣れたものです。あまり馴染みのない東京のどこかの駅より、サンフランシスコのほうが土地勘があるぐらいです。

過去3回は自分でホテルも飛行機も予約していましたが、今回は金の力を使ってツアーで行きました。すべて手配してくれます。サンフランシスコ空港から市内へ行くのに、自分で電車に乗る必要がありません。考えてみると最近はそんな海外渡航が多い気がします。1年に1回ぐらいは自分ですべて手配して、現地の移動も公共機関を使わないと、自分がダメ人間になりそうです。

ホテルはユニオンスクエアを見下ろす場所にあるウェスティンでした。実に快適でした。ただ、ユナイテッド航空のサービスはお世辞にも満足とは言えません。3回中2回もバターが溶けた状態で出てきたのは、個人のミスではなく何か構造的な問題がある気がします。乗務員が食事の載ったトレイを軽々しく乗客の頭の上を通過させるのも気になりました。フェイルセーフの発想があればなるべく低い位置を移動させたほうがいいんじゃないかと、見るたびにずっと思っていました。そもそも乗務員のトレーの扱いが雑な印象です。向こうはプロなので自分の感覚が間違っているのかもしれませんが。とは言え、他の航空会社でこんなに何度も、機体が揺れたらあのトレー危ないな、と思うことはこんなにありません。扱いが雑だと感じたのは事実です。

キーノートを中心に今年の全体的な雑感を書きます。

今年のサンフランシスコは暖かったです。例年、昼間は暖かくても夜間が冷えます。今年は滞在した1週間のうち、夜の冷えを感じたのは1日だけでした。いつもは海からの寒風も加わり極寒になるトレジャーアイランドのコンサートも、今年は拍子抜けするほどの暖かさでした。今年が初参加となる何人かの人に、トレジャーアイランドのコンサートは寒いので気をつけろと事前に散々警告してきました。まるで自分が嘘つきだったみたいです。

なお、今年のトレジャーアイランドのコンサートのメインアーティストはエアロスミスでした。洋楽に詳しくない自分でもエアロスミスぐらいは知っています。知っている曲は1曲だけですが(映画アルマゲドンのテーマ曲)。

今年のJavaOneですが、ここ数年の中ではもっとも盛況に感じました。Oracle OpenWorldのキーノートスピーチの中で、スクリーンにJavaOne登録者数が9000人以上と出ていました。去年の入場者数は公式には発表されていないようですが、5000人から6000人という噂を聞いた記憶(あくまで非公式な噂なので正しいかは不明)があります。数字が正しければだいぶ増加しています。数字はともかく、個人の印象で、会場やキーノートにいる人の数が過去3回に比べて多く感じました。

逆にOracle OpenWorldのほうは人が減った印象でした。公式発表では、去年より登録者数が更に増えた(6万人以上)と言っていましたが。真相は不明です。数万の規模の人数になると、印象は当てにならないのかもしれません。

JavaOne初日キーノート

JavaOneのキーノートは、初日の日曜日と木曜日の2回です。初日のほうは公式色が強く、Oracle社の人が中心に登壇します。木曜日のほうはコミュニティキーノートというタイトルにもあるように少し非公式の印象になります。簡単に言って、前者のほうが堅く、後者のほうが緩い感じです。

堅めの初日キーノートは少々評判の悪いものでした。新しい発表がないのも一因ですが、司会が淡々としすぎて会場を盛り上げる感じがなかったからだと思います。Java8リリースという、近年のJavaの一大ニュースすら淡々と語り、会場がたいして沸かない有様です。

カーシミュレータのデモも最初から最後までまったく意味不明のまま終始しました。去年はチェスで盛り上がったけど今年はどう?という振りに、任せとけとばかりに始めた割に、ぐだぐだな印象でした。最初、デモが失敗して再起動しているように見えたのですが、壇上で何が起きていたか詳細は不明です。自分の英語力の問題かもしれませんが。

もっとひどかったのはIBMの発表です。ラジコンカーを会場でレースしてどちらが勝つかをアンケートしているようでしたが、何を言っているのか意味不明でした。Node-REDがスクリーンに載っていたので、この辺が関係していたのかもしれません。後はBlueMixの話をしていました。BlueMixはPivotal社のCloudFoundryをベースにしています。最近のIBMは、MongoDB、Riak、Chef、Node.js、Dockerあたりと提携なのか後押しなのかわからない関係を結んでいます。これらの技術の選定基準は不明瞭です。来るもの拒まずが基本スタンスなのかもしれません。

去年まではJava8のラムダ式を並列プログラミングの文脈で説明することが多かったのですが、今年は下記のように説明していました。このスタンスの変化は興味深いです。

  • Generics: abstraction of data
  • Lambda: abstraction of behavior

Java SEのロードマップをMark Reihold氏とBrian Goetz氏という最近のJavaの技術の顔の両名が語り始めましたが、時間切れで説明が尻切れとんぼで終わりました。この説明は木曜日に持ち越されました。なお、Java EE8のほうは、HTTP2.0対応、JSON Binding、CDI2.0、MVC1.0あたりが注目です。

Oracle OpenWorldキーノート

初日、JavaOneキーノートの後に同じ会場でOpenWorldキーノートがありました。

OpenWorldのキーノートの会場は例年どおりモスコーニです。去年より会場が狭くなった気がします。もし同じ広さだとしたらスクリーンの大きさや配置の変化で小さくなったと錯覚しているのかもしれません。JavaOneの初日キーノートも同じモスコーニですが、去年までは、JavaOneキーノートとOpenWorldキーノートで明らさまに広さが違いました。今年はあまり違いを感じませんでした。これは結構な驚きです。と言うのも、過去3回の経験では、OpenWorldのキーノートは圧倒的な広さと人の多さが印象的で、それに比べたJavaOneキーノートのしょぼさが際立っていたからです。

OpenWorldのキーノートと言えば、Larry Ellisonです。今年も健在、どころかここ数年で一番元気だった気がします。

今年のOpenWorldの一押しはOracleクラウドです。世間的にはクラウド一押しは別に珍しくもなく、どちらかと言うと遅いぐらいではないかという気がしますが、Larryにかかると違います。IaaS、PaaS、SaaSとクラウド3層すべてを提供しているのはOracleだけだと強調します。GoogleとMicrosoftも3層すべてを提供している気がしますが、Larryいわく、Oracleだけらしいです。何度も何度も自信満々にOracleのみ(we are only one)だと言い張ります。言ったもん勝ちです。たいへん勉強になります。

冷静に考えるとLarry Ellisonの今回のキーノート、意外に内容はありません。にも関わらず引き込まれます。冒頭、Oracleクラウドにより30年前からの約束を果たした、と言います。その約束が何かを明かさないまま話を引っ張ります。ようやく明かした約束は、ユーザアプリのソースコードを変える必要がない約束、というものです。なんじゃそれは、と椅子からずり落ちたくなるほどのネタです。オンプレミス環境とクラウド環境の間でアプリを移動する際、OSもミドルウェアも同じなので、アプリのソースコードを変える必要がないのは自明な気がします。しかしこれを30年前からの約束を果たした、と大きな物語にしてしまうのが流石です。勉強になります。

Oracleクラウドの説明は、SaaS、PaaS、IaaSの順でした。内容がある順に話した印象です。つまりSaaSに話すネタはたくさんありますがIaaSには特にないという感じです。

SaaSはOracleのFusionアプリをクラウド提供する話です。日本だとERPと大きくくくってしまうアプリ領域をOracleは、CX(Customer Experience)アプリ、HCM(Human Capital Management)アプリ、ERP(Enterprise Resource Planning)アプリと3分野に分類します。CRMやSFAなど顧客管理系アプリはCX、人事給与やタレマネなどの人事管理系アプリはHCM、会計やSCMなどがERP、という分類です。これがグローバル基準なのかOracle固有の分類なのかは不明です。

PaaSはWebLogicとOracle DBの組み合わせです。この環境にJava EEアプリをデプロイします。IBMはCloudFoundryベースで行くようですが(後述)、OracleクラウドでCloudFoundry対応の話は出ませんでした。Java EEの次期バージョンにPaaS対応の話題はあります。CloudFoundryと別路線になるのか、あるいはRedHat社と組んでOpenShiftを推すのか、あるいは結局CloudFoundryを取り込むのか、まだ決まっていないようです。

IaaSについてはほとんど言及がありませんでした。後で聞いた話ではまだOracle Linuxしか提供可能OSがないようです。OpenStackの言及はありませんでした。

技術的な話でOpenWorldで興味深いと思った話はSPARCプロセッサのM7の話です。どこまでやるかは不明ですが、JavaやOracleに都合の良い命令セットを持つという話です。一例としてデータ圧縮の復号処理やSQLの日付のbetween処理をハードウェアで実行する話をしていました。前者はともかく(インテルCPUが暗号処理をハードウェアで実行するのを考えると、データ圧縮の復号のハードウェア処理がそんなに奇抜とも思えません)、SQLの日付between処理はだいぶ奇抜に感じます。もちろんCPUがSQLを解釈するわけではなく、整数のbetween相当の処理、が本質だとは思いますが。

火曜日のキーノートにLarry Ellison再登場しました。

基本的にはOracleクラウドの話が中心ですが、SFDC(salesforce.com)への攻撃も忘れません。SFDCもOracle DBとJavaを使っているから、我々のプラットフォームが優れているのだという主張に加えて、しかしSFDCはプロプライエタリなPaaSだとばっさり切り捨てます。

もうひとつ興味深かったのは、Oracle(RDBMS)、NoSQL、Hadoopの3種類のデータソースに対して、どれにもSQLにクエリを投げられるOracle BigData SQLです。実態は不明です。

JavaOneコミュニティキーノート

木曜日のJavaOneコミュニティキーノートは、初日に中途半端だったJava9の話が少しありました。Project ValhallaProject Panamaです。

この中で今回フォーカスしたのが、Project Valhallaの中のValue typeの話でした。現状のJavaは、intやdoubleなどの基本型を敢えて無視して、オブジェクトと参照という世界に限定すると、ある意味、美しくて説明しやすい世界があります。ただ、ここには、美しさと引き換えに効率さを犠牲にしている側面があるのも事実です。この非効率さはコンパイラやJVMが裏で隠蔽していく流れだと思っていました。ここに来て、メモリレイアウトを意識させる言語仕様になるのは、抽象化の観点から見ると退行に感じます。Javaはアプリケーション記述言語からシステム技術言語へ立ち位置をシフトしていくのかもしれません。あるいは既にとっくにそういう流れかもしれませんが。

JavaOneコミュニティキーノートは去年からIoTが中心テーマです。更に今年目立ったのはロボットです。ALDEBARAN社も登場しました。サンフランシスコの地で、スクリーンにSoftBankグループの文字やPepperを見るとは思っていませんでした。

去年のJavaOneでIoTの連呼を聞いた時、正直、Java MEに未来があるとは思っていませんでした。客観的に見て、組み込み系の世界ではAndroidがJava MEの市場を奪っていると思えたからです。しかし、今年のロボット連呼を見ていると、少し考えが変わりました。ロボットのOSがすべてAndroidになるとは限らず、多様なOSが存在して、その上でJavaというのは、無いことは無い未来だからです。

コミュニティキーノートの後半は様々な事例が駆け足で発表されました。

RoboVMlodgONによる、Java8とJava FX8をAndroidとiOSで動かす紹介がありました(Java FXPorts)。Dalvik VMはJava7だけど、我々のプラットフォームを使うといち早くJava8でAndroidアプリを書けると自慢していました。

これらに未来があるのか不明です。客観的には、Java FXで書いたアプリは、Windows、GNU/Linux、Macで動き、更にこれに加えてAndroidとiOSで動くので、かなり強力な選択肢と言えそうです。手離しで乗る気になれないのは、GoogleとAppleの両方から無視されている存在だからです。そもそもOracle OpenworldおよびJavaOneに来て思うのがGoogle無視の徹底ぶりです。裁判の関係とは言え、今、Google完全無視でITの世界を語ろうとすると、どうしても無理が生じます。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ, 勉強会.

このエントリーを含むはてなブックマークはてなブックマーク - COMPANY Forum 2014に行ってきました このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - COMPANY Forum 2014に行ってきました Share on Tumblr Digg This

COMPANY Forum 2014に行ってきました。と言っても、セッションの1つにパネリストとして参加したので内部の人としてですが。

事前に登録者数1万人越えと聞いていたので、受付が大変な混雑になると思っていました。7月に品川であったAWS Summit Tokyo 2014も確か1万人規模の人が集まり、受付が相当に混雑したからです。しかし、当日、思ったより受付が整然としていました。COMPANY Forumの場合、2日間で1万人なので1日当たりの人数はAWS Summitに比べて少ないのでしょう。また、COMPANY Forumは会場が3カ所に分散していたせいもありそうです。

初日の午前はキーノートです。牧野さんの話(HUEの発表)は事前に知っている内容ですし、内部関係者みたいなものなのでコメントは控えます。その後、今回の目玉とも言えるスティーブ・ウォズニアック氏が登場しました(フロリダとのビデオ中継)。

ウォズニアック氏の印象ですが、一言で言うと、よく喋るな、です。牧野さんとの対談形式ですが、牧野さんの質問に1つに対して、ひたすら喋り続けます。とにかく止まらない。牧野さんも大変そうでした。

ウォズニアック氏の話の主張は、エンジニア中心主義を徹底していました。エンジニアだけが問題解決できる、イノベーションを起こしたければプロジェクトにエンジニアを入れるべき、と言った感じです。少々物事を単純化しすぎな気がしますが、そういうスタンスの人なのでしょう。

興味深かったのは、Apple社はGoogle社と比べてクローズドな会社ではないのかという牧野さんの質問です。それに対して、ウォズニアック氏が、自分自身はオープンを支持する人間だが、ジョブズは違うようだと回答したのは、正直で好感が持てました。そのままApple社の批判をしてくれれば主張に一貫性があってウォズニアック氏を讃えたいところですが、そうもいかず、全体としてはApple社擁護で終わりました(Apple社はオープンとクローズドをうまくバランスしている)。一貫してApple社のクローズドな姿勢を批判するFSFを見習ってほしいものです。

2日目は午前中に伊藤穰一氏と野茂英雄氏、夕方に安藤忠雄氏の講演を聞きました。どれも面白かったです。そして言葉に重みがあります。

しかし、みんな成功したから言える、という部分はあります。その辺を率直に語っていたのは野茂英雄氏でした。成功の秘訣なんてわからない、うまく結果を残せたから言えるだけだと。その点、安藤忠雄氏は成功の秘訣を聞かれ慣れたせいか、開き直って、ストレートにがんがん語っていました。普通のことやっても世界えは成功できないと。当然ですが、変わったことをすれば世界で成功できるわけではないのも厳然たる事実です。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under .

このエントリーを含むはてなブックマークはてなブックマーク - 「実践 反復型ソフトウェア開発」を読みました このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - 「実践 反復型ソフトウェア開発」を読みました Share on Tumblr Digg This

元ロータス、執筆当時はマイクロソフトにいた津田さんの力作、「実践 反復型ソフトウェア開発」を読みました。

津田さんはロータス時代の自分の同僚です。本を読んだ理由は津田さんに会ったからです。会う前に読むつもりでしたが、諸般の事情で読むのが会った後になりました。

判型が小さめでそんなに分厚くもないので(薄くもないですが)、軽く読めると思っていました。が、思ったより字が小さくずっしりと重い本でした。読み応えのある本です。少々詰め込みすぎに感じますが、書籍なのでこれぐらい情報を詰め込んだほうがお得感があります。とにかく丁寧に用語を定義する本です。津田さんの軽妙な語り口のおかげで、すいすい読めます。

読んでいると、15年前(実はもっと前…)、津田さんとともにロータスにいた頃をふと思い出したりしました。

ロータス入社当時、まわりが当然のように口にしているのに、自分の知らない用語がありました。コードフリーズとかトリアージとかRC(リリースキャンディデート)とか。当時、はじめて聞く用語でしたが、知らないと言えず、文脈から意味を推測していました。Google登場以前とは言え、既にサーチエンジンが国内外問わず色々あったはずなのに、Webで単語を調べる習慣がありませんでした。今から思うと不思議です。

書籍ではなく会ったときの話を少々。

津田さん、大谷さんと40代を迎えたいい大人同士で集まって、これまでのキャリアとこれからのキャリアについて静かに語りました。そこでの津田さんの印象深い言葉が、影響力のある人間になるべきだという主張でした。昔、仙石さんから聞いた話にも通じます。

本当に偉大な人間であれば自分が中心になって世界を変えようと思うのかもしれません。そうでもない凡人は、自分のまわりに良い影響を与えることを自分の存在価値にするのがちょうど良いのかもしれません。良い影響力と言うあたりもバランスが良いです。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.

このエントリーを含むはてなブックマークはてなブックマーク - JavaScriptとCSSを1ファイルに このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - JavaScriptとCSSを1ファイルに Share on Tumblr Digg This

フロントエンドの最適化手法の1つにJavaScriptやCSSのファイルを1つに結合するというのがあるので、ついでにJavaScriptとCSSを1つファイルにまとめてみました。

非標準ですが大抵のJavaScriptエンジンの実装では<!–が1行コメントになることを利用してJavaScriptとCSSを切り替えてます。確認したとこIE8、Firefox33、Chrome37では意図通りに動作しました。IE11ではMIMEタイプが違うといわれてCSSが適用されませんでした。

思いつきなんで効果の程は知りません。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.

このエントリーを含むはてなブックマークはてなブックマーク - アリエルの開発を支える Trac このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - アリエルの開発を支える Trac Share on Tumblr Digg This

先日 アリエルの開発を支える Trac プラグイン を書きましたが、今日は課題/バグ管理システムの Trac 本体について書きます。

Trac は Edgewall Software が開発した Web ベースの課題管理システムです。修正 BSD ライセンス、オープンソースとして提供されています。いまはどうなっているか分かりませんが、サイト上では Edgewall Software 自身も Trac のコンサルや商用サポートを行っているように書かれています。また、

edgewall.org is a place where a community of software developers collaborate on creating exciting open source software based on the Python programming language.

とあるので Trac をホスティングしているサイト自体は開発者向けに開かれた場所として提供されているようです。Trac Team の情報をみる限り、現在 Edgewall Software の開発者は積極的に関わっていないようです。

 

Trac 0.12.x から 1.0.x への移行

アリエルでは2013年12月頃に 1.0 系へ移行しました。もう半年以上も前のお話になるため、いまは解決済みの内容もあるかもしれませんが、実際に移行していて遭遇した問題などを紹介します。社内で Trac は業務における一次情報を提供するインフラになっていて、これが止まると業務への影響が大きいため、移行そのものに心理的に慎重になってしまっていました。

アリエルで移行したバージョンは、0.12.1ja から開発中の 1.0.2-trunk にしました。当初は 1.0.1 にしようと試みました。しかし、Genshi 0.7 との組み合わせで #11218#11261 のエラーが発生したため、当時の 1.0.2-trunk を使うようにしました。その時から 1.0.2-trunk が開発終盤だったのもありますが、移行を阻害するほどのトラブルはなく、結果的には 1.0.2-trunk を選択して良かったように思います。

このブログを書く前にリポジトリを更新して、いまは trac:r12928 で運用しています。

 

移行中に報告して直してもらったバグ

移行中に発生して Trac Team に直してもらったバグです。修正方法をみていると、Trac の開発チームは最も古いメンテナンスブランチ 0.12-stable にパッチを適用し、その後 1.0-stable, trunk にポーティングするというスタイルを取っているようです。1つのパッチから、一緒に3つのブランチを保守するのはなかなか大変なようにみえます。

DB に postgresql を使っていて、マクロがエラーになったときに postgresql がエラーメッセージとして日本語を含む str 文字列を返し、Genshi がそのエラー文字列を表示するときに Unicode 文字列を期待して UnicodeDecodeError が発生していました。うろ覚えですが、TicketQuery マクロで format を指定せずに col にチケットのカスタムフィールドを指定したときにマクロがエラーになったように思います。0.12 の頃は動いていたので 1.0.x で format 指定が必須になったのかもしれません。

NG: [[TicketQuery(...,col=summary|owner|custom-field)]]
OK: [[TicketQuery(...,format=table,col=summary|owner|custom-field)]]

この Genshi のエラーはなかなか致命的で、レポート一覧を開いたときに個々のレポートが評価されてエラーになっていました。レポート一覧にレポートが200以上あったため、どのレポートが原因かを突き止めるのが面倒でした。

これは Firefox のみに影響する不具合です。Trac はコメントの入力中の、キーボード入力が一定時間止まったときにプレビューを表示します。どうも Firefox は IME が有効なときに keydown や keypress のイベントを発生しないようです。Firefox で IME を切り替えて入力していると、入力中であってもプレビューが表示されて鬱陶しいといった不具合でした。

移行の全体を通して Genshi が関連するトラブルが多かったように思います。Genshi 自体の問題ではないのかもしれませんが、Genshi のバージョンと Trac のバージョンの組み合わせで発生する問題もありました。通知メールのテンプレートの改行コードに CRLF を使うと、送られてくるメールにバックスラッシュが混入します。Genshi-0.6.1 では再現しません。0.7 ブランチと trunk に修正パッチが取り込まれていますが、そのパッチを含む Genshi-0.7 がまだリリースされていないため、アリエルの環境では Genshi-0.6.1 を使っています。

 

移行中に遭遇した問題

ここではバグというわけではなく、アリエルでの Trac 利用においてのカスタマイズを紹介します。プラグイン同様、Trac 本体に適用しているパッチも https://github.com/arielnetworks/trac で公開します。それぞれの修正はブランチ単位で管理しています。

  • 通知メールの改行コードを CRLF に変換

EdMax というメーラーを使っている開発者がいて、このメーラーが LF を改行として認識してくれません。Trac の過去のチケット (#2191, #1139) をみると通知メールの改行コードに CRLF を使うように対応したように伺えたのですが、なぜか LF が含まれるユースケースがあるようです。再現方法を調べきれていないため、チケット登録はしていません (1.0-stable-replace-lf-to-crlf-notification) 。多くの開発者が使っている Thunderbird では再現しないのでどっちでも良い気もしますが、RFC 2046 によると CRLF を改行コードに使うのが正しいようです。

  • チケットの添付ファイルフィールドの開閉状態のデフォルト設定

チケットの添付ファイルのフィールドの折り畳みのデフォルトが変更されたようです。0.12 では折り畳まれず開いた状態でしたが、1.0 からは折り畳まれるようになったようです。開発者だけでなく、全従業員が Trac を使うのであまり慣れてない人が添付ファイルを見逃してしまうかもしれないという経緯から修正しました (1.0-stable-expand-attachments-in-ticket) 。trac.ini で設定できても良さそうにも思いますが、チケットを作るほどでもないかなと一時対応した状態です。

リポジトリ連携のコメントに更新したファイルを表示する機能拡張です。Trac のマイルストーン 1.1.3 で取り込まれる予定です (1.0-stable-add-config-option-show-changeset-files) 。もともとは TracChangeFileBiffPlugin を作ったとき、ついでにコメントから更新ファイルを一見して分かると便利だというところから出てきたものです。ぱっと見てどういったファイルを更新しているかが分かるのが良いです。

trac-dummy2

 

Trac プラグインの非互換な不具合

アリエルでは20~30個ほどのプラグインを使っています。プラグインがたくさんあると、移行のときの互換性が気になりますね。この機にもう使っていないプラグインもいくつか削除しました。

TracTags は準標準的なプラグインです。私が移行しているときは 0.7 の開発バージョンで、且つ DB のテーブルのスキーマを更新したため後戻りができず、このチケットのエラーに悩まされました。いまは 0.7 の正式バージョンもリリースされているので大丈夫です。

DefaultCcPlugin の管理画面で設定をしようとすると、コンポーネントが重複して表示される不具合です。表示だけの問題だったので運用に影響は与えませんが、すぐに直してくれました。

 

Trac Team へのお礼

移行を通して上述した Trac/TracPlugin の不具合に対応して頂いた Trac Team の Ryan Ollos 氏 と Jun Ōmae 氏 (@jun66j5) に感謝します。おかげで大きなトラブルなく移行できました。ありがとうございました。Trac 開発に協力したい方は What is a good patch? を読んでコントリビュートすると良いと思います。

 

Trac 開発とロードマップ

せっかくなので Trac の開発状況も少し整理してみましょう。

 

1.0.2 のマイルストーン

現時点の マイルストーン 1.0.2 によると、94%完了しています。が、スケジュールが17ヶ月遅延とあるように、もはやマイルストーンとして意味を成していません。社内で移行作業を行っていた2013年12月頃も95%前後だったように思います。当時は、ほぼ 1.0.2 の開発が終わってるからいいかと選択したのですが、あれから半年以上経ってもリリースされていない状況です。Trac Team が何もしていないわけではなく、その後もチケットが登録されては直すの繰り返しが続いているようです。

社内で運用していている分には特に困ることはなかったのでみえない所の品質が改善されているのかもしれません。メーリングリストのやり取り をみると、いまあるチケットが close される2週間後あたりを目処にリリースされるそうです。1.0.2 がリリースされたら、この移行記事を書こうと思っていましたが、いつリリースされるか分からないので先に書いてしまいました。

 

Tracのロードマップ

Road Map によると、3つのバージョンがあります。

  • 0.12系: 2010年6月にリリース、LTS (Long Term Support) として保守
  • 1.0系: 2012年7月にリリース、バージョン番号を刷新
  • 1.1.系: マイナーバージョンの奇数は開発版としてリリース

0.12系は多くのプラグインとの互換性を維持するためにそう簡単には破棄できないようにみえます。プラグインのメンテナンスが追いついていない現状をみると、プラグインが動かないために 1.0 に移行できないケースはあるかもしれません。準標準的なプラグインはほとんど 1.0 に対応しているようにみえますが、メンテナンスされてないプラグインをどうするかが移行の今後の課題のようにみえます。

また TracHacks の運用の問題もあります。プラグインのメンテナーになる方法は Adopting Hacks に記載されています。しかし、メーリングリストにリクエストを送って承認してもらい、Subversion のリポジトリのアクセス権限をもらうといった、いまどきの github で PR を送り合う文化と比べると、手順が面倒なので勢いでメンテナーになるといったことはなさそうに思います。こういったインフラも含めた体制の移行はかなり大変で、いまの Trac コミュニティにそこまでの熱意をもった人がいるのかどうかは微妙なところだと思います。

先日の記事で、当社でもメンテナンスされてない Trac プラグインにパッチを適用したリポジトリを公開しました。使っていて不具合があれば修正はしますが、メンテナーになるほどではないといった開発者のモチベーションを有効活用できない管理体制にみえます。

閑話休題。1.0 以降の開発では、stabledevelopment の2つのブランチに分けることで開発を加速させることを狙いとしています。0.12 から 1.0 のメジャーリリースに2年かかっていることを憂慮しての、それよりも早く同等のリリースを行いたいように伺えます。とはいえ、いま2014年7月で 1.2 がリリース時期すら未定なので意図したように実際には進捗していないようです。マルチプロジェクト対応が 1.1 リリース の目玉機能なので 1.2 の登場は待ち遠しいですね。

 

Apache Bloodhound の存在

Trac とは違う未来の可能性も考えてみます。Trac の課題の1つとして開発やプロジェクトマネジメントそのものが停滞しつつあることは述べました。

さらにオープンソースではあるものの、コミュニティサイトの運営も含め、Edgewall Software が開発/運営しているものというイメージが付くことを問題と捉える人もいます。そんな人たちが vendor-neutral な開発体制への移行を促す意図で発足したのが Apache Bloodhound のようです。Incubator プロジェクトとして発足したときのアナウンスが [PROPOSAL] Apache Bloodhound です。これによると、当初は WANdisco という会社の開発者たちが中心になって開発し始めたようです。

その後、Incubator プロジェクトを卒業して Top-Level プロジェクトに昇格しました。2013年8月にバージョン 0.7 がリリースされています。機能的には、Trac と比較して以下に焦点を当てています。

  • マルチプロジェクト対応
  • 全文検索機能
  • ユーザーフレンドリーなデザイン
  • インストールが簡単

Trac 自体の、開発プロジェクトとしての反省から BEP (Bloodhound Enhancement Proposal) という PEP に倣った機能拡張や仕様を提案する方法も取り入れたり、先に述べたマイルストーンの事実上の崩壊にならないよう リリースプロセス を明確にしています。さらに UI スクリーン/情報アーキテクチャ も整備されています。Trac 0.12 からの移行 もできるとありますが、内容をみると Trac 0.12 から 1.0 への移行とあまり変わらないようにみえます。

試しに apache/bloodhoundリポジトリ から trunk をチェックアウトしてインストールしてみました。インストール時に admin ユーザーを作成できるのは簡単で良いですね (いまどき当たり前ですが) 。UI も刷新していて Trac に飽きてきた感のある人には良さそうです。

インストール直後にプラグインを見てると、Bloodhound のツール群は Trac プラグインの1つとしてみえるようです。

bloodhound-admin-plugin1

目玉機能のマルチプロジェクトです。管理画面上では、プロジェクトではなく プロダクト として管理するようです。UI はよくできています。このプロダクト単位にチケット番号が1から割り当てられます。

bloodhound-multiproject1

当然、チケットの関連付け (BEP-0006) も作れます。いまのところ、プロダクトを跨ぐ関連付けはできないようです。

bloodhound-ticket-relation1

簡単にインストールして使ってみた限りでは、機能は申し分ないですが、プラグインである点にがっかりしました。

てっきり Apache Bloodhound が Trac を fork して作り直すんだと勘違いしていました。今後どうなるのか分かりませんが、現状では Trac プラグインの再発明と UI を置き換えたもののようにみえます。穿った見方をすれば、Trac の開発が停滞しているのは Edgewall Software の vendor-neutral じゃない性格によるものだと言いたい人たちが Apache Bloodhound という名前に変えたようにも受け取れます。Apache プロジェクトなら vendor-neutral にこだわる開発者も確保できるんじゃないかという問いかけとしてはおもしろいですが、いまのアーキテクチャをみて手伝おうとは思わないでしょう。そこそこの規模の5つのプラグインが、依存関係をもって提供されています。

Trac のエコシステム (プラグイン) を放棄するのは覚悟がいるからそうそうできないでしょう。Trac 開発がいま以上に停滞してしまったら、それなりに需要はあるかもしれませんが、Trac 開発がまた勢いを取り戻せば Apache Bloodhound と Trac のバージョン間での管理コストが増大していき、いずれ Apache Bloodhound のメンテナーがいなくなっていって、いまの TracHacks の状況と同じ歴史を繰り返すんじゃないかという気がします。

もうしばらく Apache Bloodhound のバージョン 1.0 が出るぐらいまで、その動向を伺ってみようと思います。


関連文書:

Posted by & filed under 開発.

このエントリーを含むはてなブックマークはてなブックマーク - アリエルの開発を支える Trac プラグイン このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - アリエルの開発を支える Trac プラグイン Share on Tumblr Digg This

アリエルの開発は、いわゆる チケット駆動開発 に分類されるわけですが、課題/バグ管理システムに Trac を使っています。最近の Trac 自体の開発は活発とは言えないし、Apache Bloodhound も出てきたりしていて、その未来がどうなるのか懐疑的なところもありますが、懸命に保守してくれる開発者もいるので、まだまだ数年は安心して使えるように思います。

そんな Trac は minimalistic な基本方針により、足りない機能をプラグインで拡張するのが一般的です。このプラグインという過去の遺産が Trac を課題管理システムとして有力な候補の1つに押し上げているとも言えます。Trac のプラグインは TracHacks で探してそのリポジトリからインストールできます。プラグインを PyPI からインストールできるように trac.plugins の名前空間を使う 方法もありますが、PyPI で公開されているパッケージを俯瞰すると、おそらくは歴史的な経緯でこちらの方がマイナーな方法にみえます。

 

アリエル製 Trac プラグイン

さてタイトルの本題です。アリエルで開発した Trac プラグインを紹介します。詳細な説明はリンク先をみてもらうとして、その目的や背景と用途を簡単に紹介します。

これらのプラグインの見た目はこんな感じです。

trac-dummy1
trac-dummy2
trac-dummy3

 

TracTicketReferencePlugin

minimalistic な方針とのトレードオフですが、チケット同士の関連付けを行う機能すらありません。私の知っているバグ管理システム (Bugzilla, Mantis, Redmine) で、この機能が標準で提供されていないのは Trac だけです。いまどき全く困ったもんです … という経緯から作られたのがこのプラグインです。最低限のチケットの関連付けとコミットフックとの連携ができるようになっています。

InterTrac でのチケット関連付けの 要望 は社内外からあるのですが、Trac 自体の TracLinks と InterTrac との境界が曖昧で、それらをどう扱えば良いのかがちょっと調べた限りでは、よく分からなくてずっと放置状態です。がんばればできそうだけど、そのモチベーションもインセンティブもないような機能は、最近だとクラウドファンディングしたりするといいのかもしれないなと思ったりもします。

TracMultiSelectBoxPlugin

この機能も minimalistic な方針とのトレードオフです。複数選択リストが標準で提供されていません。この種のプラグインも古からのものから、リッチ UI なものから、探せばたくさんあります。軽量/シンプルな機能性と Trac 本体で提供される text の list フォーマットを使う ことで将来的な互換性も保持することを狙いとして作りました。いずれ Trac 自身に複数選択リストの機能が入るでしょうから、それまでの繋ぎとして使うプラグインです。

TracChangeFileBiffPlugin

限定的な用途ですが、コミットフックでリポジトリ連携するときに特定のファイルパターンを検知して、そのチケットにフラグを立てるプラグインです。上記のサンプル画像では、*.properties に対してプロパティファイルというフラグを立てます。TracMultiSelectBoxPlugin と併用すると便利です (もともと TracMultiSelectBoxPlugin はこのプラグインのために作ったものでした) 。社内では、プロパティファイルの他に、メッセージカタログに対する更新を監視して、チケットが fix された後にテスターがベリファイするときに日本語/英語のメッセージ確認を見逃さないようにするために使っています。

 

その他のプラグイン

アリエルでは20~30個ほどのプラグインを使っています。ほとんどは一般的によく使われるものだと思うので、最近導入したプラグインで良かったものをいくつか紹介します。

TracAdvancedSearchPlugin

Trac の標準検索機能はデータベースに対する検索となるため、データの増加に伴ってどんどん遅くなります。以前は Trac の標準検索機能で10秒前後かかっていた全文検索が、このプラグインにより1秒未満に短縮されました。全文検索のバックエンドには Apache Solr を使います (いまのところ対応しているのも Solr のみ) 。Solr の構築はちょっとややこしいですが、そのコスト以上の快適さを得られます。

いまの仕組みとしてチケットにコメントが追加されるごとに、そのチケット情報とコメントのテキストを全てインデクシングし直すといった効率の悪いことをやっています。それでもアリエルの環境 (インデクシングのリクエストを非同期モードにする、チケットのコメントは数百程度) では、特に運用トラブルが起きていないので大丈夫そうです。まだマージされていませんが、#29 の pull request を取り込むと全部検索のノイズを減らせます。

TracTicketFieldsLayoutPlugin

上記の1番目のサンプル画像で「基本項目」と「拡張項目」にグルーピングされているのに気付きました? Trac を運用していく中でどうしてもカスタムフィールドが増えてしまいますね。いろいろなフィールドがあってごちゃごちゃになりがちです。これらの項目は◯◯の運用に使うものといったグルーピングをすることで、見た目がすっきりするだけでなく、フィールドを探すのも容易になります。管理画面の UI も優れていて簡単に設定できます。

TracChangeFileBiffPlugin のデータの持ち方もこのプラグインの実装をお手本にさせて頂きました。

WikiExtrasPlugin

もうメンテナンスされていないようで残念な感じですが、Trac での表現力をあげるマクロやアイコン (上山根 祐輔氏 が クリエイティブ・コモンズ 表示 3.0 ライセンス で公開しているもの) を提供します。見た目はこんな感じです。

trac-wikiextras1
 
trac-wikiextras2

 
trac-wikiextras3

 

メンテナンスされていないプラグインに対するパッチ

過去の遺産であるプラグインが多いのは Trac の魅力の1つですが、便利なプラグインであってもメンテナンスされていないものもたくさんあります。アリエルで利用しているプラグインの中にも TracHacks へパッチを投稿したものの、残念ながらメンテナー不在で対応してくれなかったりすることもあります。社内でパッチを管理するのが面倒になってきたのと、github に置いておく方が社内外でも扱いやすく、他にも困っている人がいたら役に立つかもしれないし、どんどん公開していくことにしました。同じようにパッチ管理している人がいたら活用してください。

今後も何か問題があったら増えていくかもしれません。


関連文書:

Posted by & filed under 勉強会.

このエントリーを含むはてなブックマークはてなブックマーク - 社内 Python3 プログラミング勉強会 このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - 社内 Python3 プログラミング勉強会 Share on Tumblr Digg This

先月、Python3 でコーディングする機会がありました。初めて Python3 専用のツールを作ってみたのですが、作ってるうちに楽しくなってきて誰かに伝えたいと思い立ってその勢いで社内勉強会を開催しました。

社内にもいくつか Python 製ツールはありますが、サポート対象に RHEL5.x があるため、未だに 2.4 で保守を続けています。そんなうっぷんを晴らすべく「ほら! 2.4 では使えなかった構文や標準ライブラリが使い放題だよ。」と感動を伝えたはずなのに、同僚の Rubyist から「何て後ろ向きな楽しさ …」と言われてしまいました。Ruby の新しいバージョンをどんどん使えば良い的な雰囲気はうらやましいです (それはそれでメンテの苦労もあるでしょうけれど) 。

コーディングの話題へ移る前の、パッケージングの話題を盛り過ぎたのか、時間が足らなくて実際のコードを見ながらのお話が半分ぐらいしかできませんでした。説明を省いたものや消化不良になったスライドの補足、あとサンプルコードを以下にまとめました。

みんなが Python3 を普通に使うようになったらきっと世の中は楽しくなると思います。


関連文書:

Posted by & filed under いろいろ.

このエントリーを含むはてなブックマークはてなブックマーク - インドからインターンシップ生がやってきた このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - インドからインターンシップ生がやってきた Share on Tumblr Digg This

昨年に引き続き、今年もインドから2名のインターンシップ生がやってきました。彼らは大学3回生だそうです。採用チームの人事ブログで彼らの紹介があるので良かったらご覧ください。

インターンシップ生を受け入れるのは2年目なので、昨年よりは彼らが業務に携わりやすいように英語の資料やオリエンテーションの質が上がっていますが、それでもかなり不十分なのが実情です。普通の日本企業で働いていると、それだけ私たちは日本語を前提とした考え方、業務、ワークフローを構築していることに彼らが加わることによって気付かされたりもします。

日本語と英語の壁

例えば、せっかく Javadoc にメソッドの説明があってもそれが日本語で書かれているため、彼らが IDE を使っているとがっかりするだろうなと思うときもあります。それは、私も過去に中国語でコメントされたソースコードを見たときのがっかり感から来ています。あーあって気分です。

昔はバージョン管理システムで文字化けしたり、バグったりするからソースコードに日本語を書くな的なルールにも一定の利がありましたが、いまはそんなこと言うと、英語が読める人 vs 読めない人の対立になってしまうので難しいところです。ソースコードもコミットメッセージも全て英語で書いた方が良いと私は考えますが、他人へ強要するほどの根拠があるわけでもありません。余談ですが、(チケット見ないと内容を把握できないからと) チケット ID だけ書いてコミットする人もいます。あれは個人的にそのコミットの意図は何なんだ?とちょっと納得できなくて、もっと声を荒げるべきなのかもしれません。

別の例では、ある日、メンターの1人が休暇でインターンシップ生の1人から質問を受けました。彼は Trac に登録されたチケットのバグ修正を行っていたのですが、そのチケットが日本語で記述されていたため、内容を教えてほしいということでした。私が彼だったら読めないからとそんなチケットは無視するところですが、彼は自らもインターネットの自動翻訳サービスを活用して英訳しつつ、その内容を理解しようと努めていました。そういうところは若い人の真摯さ、おっさんになると偏屈になってしまうことを実感するときでもあったりします。

郷に入れば郷に従えという考え方がインドにあるかどうか知りませんが、ここは日本なのだから日本語を使うことそのものに問題はないけれど、せっかくのコミュニケーションの機会を失うことにも繋がるという点で残念だなと思ったりもしました。彼らのためにチケットの内容を全て英訳しようとか、コメントを必ず英語で書きましょうとか、費用対効果を考慮するとそんな業務指示は絶対に出ないのですが、外国人とのコミュニケーションに挑戦しようとか、楽しんでみようといった視点からやってみると敷居が下がって良いんじゃないかと思います。

学生時代のなにか

最近「後生畏るべし」ということばを知ったのですが、彼らをみていると正にそんな印象を受けます。確か2人とも日本に来るのは初めての経験で、インドから海外へ出るのも初めてだと聞いた気がします。学生からよく聞く質問で「学生時代に何をしたら良いですか?」といったものがあります。で、無難 (?) な答えに旅行に行きなさいといったものが一番多いように思います。私が学生の頃にも、何人かの社会人の方に学生のときに旅行に行った方が良いと勧められた記憶があります。

私はいまになって気付いたことですが、ここで言う旅行というのはなるべく海外へ行った方が良いということだったんだと思います。自分が学生の頃は海外へ行ったことがなくて、20台の後半になってお仕事で北京へ3ヶ月間行きました。海外へ出たのもそのときが初めてでした。そこで1ヶ月経ったらホームシックになって早く日本に帰りたいと思いながら、3ヶ月間、辛い日々を過ごしました。自分自身、英語がほとんど話せないし、当時の中国では一般の人には簡単な英単語もほとんど通じません。何というか時間が経つほど、すごい孤独感を実感するようになりました。そういったものはお仕事のモチベーションにも大きく影響を与えるので他国で働くというのはすごく大変なことなんだと、そのときになって私は初めて気付きました。

そういうことを経験してから彼らをみると、彼らの優秀さ、大変さ、そして後生畏るべしだなと思うわけです。学生時代に何をしたら良いかの質問にあえて答えるとしたら、何か目的がなくても良いからただ海外へ行って、そこで数ヶ月過ごしてみるのも良いかもしれません。観光しても良いと思うし、留学しても良いと思うし、ただ一定期間、外国にいることで得られるものがあるように思います。

まとめ

話が発散したのでまとめられなくなりました。インターンシップ生の彼らをみていて受ける刺激がどういうものかの一端を紹介してみました。おかげで久しぶりにこのブログにも投稿できました。


関連文書:

Posted by & filed under いろいろ.

このエントリーを含むはてなブックマークはてなブックマーク - Sphinxの全文検索を複合語に強くする このエントリをつぶやくこのWebページのtweets この記事をクリップ!Livedoorクリップ - Sphinxの全文検索を複合語に強くする Share on Tumblr Digg This

最近社内のドキュメントは殆どSphinxで書いてます。しかしどうも検索の精度が悪い、特に複合語がヒットしないと言われたので改善してみました。Sphinxのバージョンはv1.2.2です。

まずはドキュメントに全文検索機能を追加する

こんな方法で追加しました。

  1. sphinx-quickstartでドキュメント作成
  2. conf.pyに全文検索の設定を追加
    python
    html_search_language = 'ja'
    html_search_options = {'type':'default'} # build server using type:mecab
    
  3. make html

改善案1: searchtools.jsを賢くする

_build/html/_static/searchtools.jsパッチを当てます。

生成物にパッチを当てるのは気持ち悪いけど説明の簡便のため、というか私のSphinxやPythonへの理解が低いのでとりあえずこうします。もっとよい方法があれば教えてください。

パッチが何をしてるかというと、元々Sphinxがsearchindex.jsへ出力する索引は転置インデックスindex.termsがオブジェクトリテラルで作成されます。これだと単語が完全一致した時しかインデックスを取得できません。オブジェクトリテラルをソート済みの配列にすることで2分探索+前方一致検索が可能になります。

ソート済みの配列への変換は簡便のためSearch.setIndexでやってます。本来は変換したものをsearchindex.jsに出力したほうがよいでしょう。

こんな配列の索引が出来上がったとします。

1. ["データ", 1]
2. ["データベース", 2]
3. ["移行", 1]

2分探索はSearch._performTermsSearch内でやってます。このbinarySearchは索引内に検索語があるかどうかに関係なく検索語の辞書順での位置を返します。そこから後ろ方向に前方一致検索することで、例えば検索語が「データ」の場合「データ」だけでなく「データベース」もヒットさせることができます。

しかしこれだけだと検索語が複合語の場合、例えば「データ移行」がヒットしません。そこで2分探索の結果を前方向に、今度は検索語が索引内の単語で始まるかどうかをチェックします。そして「データ」がヒットしたら「データ」と「移行」でAND検索したものとしてその結果を返します。「データ」と「移行」が離れてる文書もヒットしますが、それが問題になるようであればdisplayNextItem内の$.ajax#completeで除外すればよいでしょう。

文書の内容や索引の作り方にもよりますが、元のよりは複合語に強くなったと思います。

改善案2: oktaviaを使う

oktaviaは渋川よしきさんが作成したFM-indexによる検索エンジンです。単語の境界に関係なくすべての文書に対し部分一致検索ができます。

非常に魅力的な検索エンジンなのですが、ドキュメントが現行バージョンの1.0に追いついてない、バグと思われる挙動がある、など導入するには少しハードルが高いという印象を受けました。渋川さんに教えていただいた内容を元に私が検証した結果を記しておきます。リビジョンは 8ed26702c90994b621dc426dd16f84debe728799 です。バージョン0.5は安定してるそうです(未検証)。

まずはoktaviaをインストールします。

git clone https://github.com/shibukawa/oktavia.git
cd oktavia
npm install

次に私の作ったパッチをマージします。

oktavia-mkindex-cliで索引を作成します。

grunt build

# -I オプションは「大文字小文字を無視した検索対応」パッチをマージした時のみ有効
./bin/oktavia-mkindex-cli -i ../_build/html/ -r ../_build/html/ -m html -u file -f .body -c 5 -t web -o ../_build/html/searchindex.oktavia.js -I

# search.htmlで使うファイルをコピー
cp ./bin/web/oktavia-jquery-ui.js ../_build/html/oktavia-jquery-ui.js
cp ./templates/sphinx/_static/searchstyle.css ../_build/html/searchstyle.css

oktaviaのファイルをhtmlに追加します。確認だけなら生成した_build/html/search.htmlを変更するのが楽ですが、本来は_templates/searchbox.htmlなどで追加するのがよいと思われます。

 <!-- headに追加 -->
 <script type="text/javascript" src="oktavia-jquery-ui.js"></script>
 <link rel="stylesheet" href="searchstyle.css" type="text/css" />
 <!-- bodyに追加 -->
 <div id="oktavia_search_form" data-index="searchindex.oktavia.js"></div>

search.htmlをブラウザで表示すれば検索可能です。検索結果がポップアップで表示されるなど元のSphinxのUIとは異なるので、元のと同じにしたい場合はoktavia-jquery-ui.jsを変更する必要があります。

searchtools.jsの改善だけでそこそこよくなったので今回はoktaviaの採用を見送りました。ただSphinxの検索エンジンをデフォルトでoktaviaにするという話もあるらしいと聞いています。もしそうなればこのような面倒な改造を行わなくとも、手軽に快適な全文検索ができるようになるでしょう。私はデフォルトでoktaviaが使える未来を望んでます。


関連文書:

  • 関連文書は見つからんがな