オープンソース化Mass++の2年目が終わりました
明けましておめでとうございました!
…いや、だってもう三が日はとっくに終わってるし…過去だし…
じゃいっそのこと旧暦にしますか。旧暦正月なら、今年は(新暦の)1月28日らしい。でもそうすると今度は未来なのか。では
じゃいっそのこと旧暦にしますか。旧暦正月なら、今年は(新暦の)1月28日らしい。でもそうすると今度は未来なのか。では
明けましておめでとうございますであろう!
- 実は書き出しを「ちゃんと生きてます!」にしようかと迷っていたのですが、実際、今年度のユーザー会の活動量は(少なくとも一見したところ)非常に少なく、成果も、残念ながら年頭の目標には遠く届きませんでした。
- もっとも、オープンソースの開発は「仕事として給料をもらって行う」のとは違うやり方が必要ですから、それに従って『実現可能な開発体制』に徐々に移行し、「できることから手を着けていく」1年間だった、と(肯定的に!)考えることも、まぁできなくはないです(とても前向き)。
開発方針の転換
- まず開発方針ですが、Mass++のコンセプトの根幹に関わるような、大きな方針の変更を2つ、行うことにしました。
(その一)装置ベンダーのnative file形式に対応するための、独自の新開発は行わない。
- 最初にお断りしておきますが、これはMass++で「今後、ベンダー独自(native)形式のファイルはサポートしない」という意味ではありません。飽くまで、「今後、(そのようなファイル形式を扱うための)独自の開発はしない」という意味です。
- 今までMass++は主要な質量分析計製造ベンダーと連携して、各ベンダーが開発した独自(native)データファイルのオープン(read)機能を実装してきました。しかしこの作業には(人的及び財政的)コストが掛かること、一部のソースについては、コンパイルする(実行可能にする)ために質量分析計本体と接続した環境でなければならない場合があること、などの理由から、現在のオープンソースでの開発体制では、独自の(自前の)開発はほぼ不可能であると判断しました。
- 更に、オープンソース・ツール&ライブラリのProteoWizardが、現在積極的にnative fileオープン機能を実装しており、定量プロテオミクスなどで多用されるSkylineなどを含む多くのソフトウェアで利用されるようになっている、ということもこの判断を後押ししています。
- 今後は「Mass++の特徴といえる分野」に開発リソースを重点配分し、新規のファイル形式への対応は「ProteoWizardのfile-read機能を利用する」という形で進めていくことになります。
(その二)UNIXに対応する。
- UNIXは2017年現在、Windows以外のほぼ全てのOSの基盤になっています。
コンピュータ用としては、
AppleのMac OS XはUNIXの一種であるFree BSDを基に作られたものですし、
今やスーパーコンピュータでも用いられるようになったLinuxは「UNIX互換OS」です。
またコンピュータ用よりも遙かに市場の大きいスマートフォン用のOSとしては、AppleのiOSはMac OS Xの簡略版であり、
最大勢力であるAndroidはGoogleが手を加えたLinuxです。
- Mass++がWindows上で実行されるソフトとして作られたのは、第一には上記「native file形式の読み書きのための、ベンダー配布のライブラリ(など)がWindows用しか存在しない」ということがその理由でした。しかしnative file対応機能をProteoWizardに任せるのであれば、この制約はなくなります。
- UNIXに対応すると、開発自体も少し容易になります。現在Mass++の開発者グループは日本国内に散在しており(主に北関東と関西)、ネット越しに開発作業を進める必要がありますが、Windows用のソフトの開発は、この状態ではあまり容易ではありません。UNIXまたはその互換環境を用いる場合、この問題の多くは解消されます。
- これら2つの方針を基に、
- まずWindows用の最終fix版をリリースする
- native fileから汎用フォーマットファイル(mzMLなど)またはMass++独自形式ファイル(msb)への変換を、このWindows版で行えるようにする
- ついでUNIX用の開発を行う
- UNIX版では、ファイルの読み込みは汎用フォーマットファイル及びmsbからの読み込みに限定する
- といった対応で開発を進め、新機能はUNIX版で実装していくことを計画しています。
- なおUNIX版の実装の具体的な仕様は検討中で、例えばJava言語で全体を書き直す可能性もあります。この場合、そのままでWindows用の実行ファイルも作成できるため、「複数OS版のリリース」が同時に可能になります。
2016年の開発実績
- 2016年は、上記の方針に概ね従って開発を進めています。
- 第一が、build manual(開発環境マニュアル)の作成で、これは第一稿はほぼ完成、OSDNサイトで公開しています。
- また第二に、「native file読み込み」と並んで現在のオープンソース版に欠けている機能である、「ピーク検出機能」について、同じくオープンソース・ソフトであるOpenMSの機能を利用するためのプラグインを製作しました(バグが残っているため現時点では未公開)。
- これらの対応に加えてファイルオープン機能を(ProteoWizard経由で)実装することによって、基本的にはオープンソース版は、島津製作所版最終リリース(ver.2.7.4)と同等の(敢えて「同性能の」とは言わない)機能を漸く回復することになります。
新アイコン導入
- ソフトウェアの機能と直接の関係はありませんが、2016年からMass++のロゴ・アイコンが新しくなりました(学会発表ポスターにも使用しています)。これは素人芸ではなく、ちゃんとしたプロのデザイナーの手によるものです(Mass++の趣旨に賛同いただいて、無償で作成していただきました。M. Yoshizakoさん、有り難うございます!)。ユーザー会幹事の間では、「2016年の最大の実績はこのアイコンだな」と、もっぱらの評判。
2016年の発表実績
- 2015年には4件の国内学会ポスター発表を行いましたが、これが時間・財政両面でかなりの負担になったため、2016年は質量分析学会(MSSJ)でのポスター発表1件に限定しています。この発表のための開発で、2016年の目標として挙げた3項目のうちの1つ「実際にMass++を用いて研究している研究者とコラボレーションした形での開発」を満たすことはできました。
- また、日本バイオインフォマティクス学会(JSBi)の研究会として2016年に発足した「質量分析インフォマティクス研究会」(ユーザー会と共通するメンバーが何人かいますが)とは連携することになり、その第1回のワークショップでは、ユーザー会代表(かつ中心的な開発者である)田中聡が「Made in Japan のオープンソース・ソフトウェアを世界へ・・・ 質量分析データ表示・解析ソフト Mass++ の現状と今後の展望」と題した講演を行いました。
- 質量分析インフォマティクス研究会は、質量分析・インフォマティクス両研究コミュニティの相互交流を促進することを目的としており、ユーザー会単独では手が出しにくい領域をカバーしているので、この連携には意義があると考えています。
2017年の開発予定
- 実は2016年は「Mass++の開発が始まってちょうど10周年」でした。というわけで、「2016年度中」に、「Mass++ 10th Anniversary Version」として、新規の「開発版(development version)」をリリースします(するつもりです。したいと思っています)。
- これは2015年6月のver.2.7.5とほぼ同じ内容・機能ですが、2.7.5は開発環境のVisual Studioのバージョンが古く(もう殆ど使われなくなった2010である)、このライブラリに依存する部分の改良が非常に難しい状況になっていました(つまり2.7.5は、バグが報告されても、直ちに修正できる保証がない状態でした)。そこで、開発環境をVisual Studio 2015に変更、対応するコードも書き直すことで、今後のbug fixやupdateを可能にします(書き直しは既に進行中です)。
- またバグが確認されたプラグインは、この段階では取り除いてリリースされ、以後2017年中に、bug fixの終わったプラグインを追加していきます(追加の度にマイナーバージョンアップします)。最初のバージョン番号としては、(正式のオープンソース版の最初ということで)ver.3を予定しています。
- その上で、このバージョンアップが一通り完了したものを、「安定版 (stable version)」とする予定です。なお一部のプラグインについては、並行して開発する「UNIX版」(バージョン番号はおそらくver.4になります)で対応し直すことになります。
- また、懸案である「開発者マニュアル」の製作も平行して行う予定です(暇を見つけて…って、いやヒマじゃないんですけどね)。
#このエントリの英語版を書くのは憂鬱だ
というわけで、皆様、はっぴー・にゅー・いやー♪
# 年末に年賀状に書くときには、「どんな年になるか判らないので」“とにかく何かいい年でありますように”という意味でA happy new yearとなるが、その年になってしまえば、「その年であることは明らかなので」aをつける必要はなく、“その年がhappyになれ”という念を込めてHappy new yearと書く、というのが一般的だそうですが…
# 正直、17年に何がどうなりそうかさっぱり見通しが立たないので、まぁ良い年だったらもう何でもいいですよ、ということで、やっぱり「あ・はっぴー・にゅー・いやー」と書いておいた方がいいような気がするw(そういえば、去年もそう書きましたっけ)。