2013年を振り返る

無事に２０１４年の元旦も迎え、少し一段落したところで、２０１３年の一年を振り返ってみたいと思う。去年は、今振り返ると本当にたくさんな出来事があった。その中でも主だったもの、今まだ記憶に新しいものをピックアップしてみたい。

第８回日本ＯＳＳ貢献者賞の受賞

２０１３年は一言で言うとイベント満載の年だったと言える。まず２月に行われたＯＳＣ東京において、第８回日本ＯＳＳ貢献者賞というものを頂いた。賞を貰うということ自体は勿論嬉しいのだが(というか正直かなり嬉しかったのだが)、この賞の受賞には、賞以外にもいろんな意味が込められているような感じがした。

まず第一に、今まで自分がLibreOfficeやそれ以前のOpenOffice.orgに対してやってきたことが、日本国内で少なからずインパクトを与えていたこと。受賞以前にも薄々と手応えは感じていたのだが、この受賞をきっかけにその手応えがより確実となった感がある。

ただこの賞には「今までの活動に対する承認」という意味以外にも「これからの期待」という意味も含まれていた気がする。なので、その期待を裏切ることなく、これからも自分なりのベストを尽くしていきたいと思う。ただだからといって今までと同じ事を今後もずーっとやっていくのはいささか抵抗があるので、自分の強みを活かしながらも常に新しい分野を開拓し、いろんな意味でいろんな形で役に立つ良質なコードをこれからも書いて行きたい。そんなこと言うといささかclichéっぽく聞こえてしまうかもしれないが、これが今の正直な気持ちなのでいたしかたない。

あ、そうそう。この賞の景品として頂いたAmazon Kindle PaperwhiteとIntel NUC、かなり役に立っています(笑)。提供してくださったNTTデータさんには大変感謝しております。

Calcのセル格納構造の大幅改変

授賞式後にアメリカに帰国(?)してすぐに始まった作業が、Calcの内部構造、特にセル格納構造を大幅に書きなおすという作業だ。これの詳細については以前に英語のブログで説明してあるのでそっちを参照して欲しい。この作業は、始める前からかなり大掛かりになることは予想していたのだが、結局なんだかんだで最初の大コミットに至るまでに３ヶ月かかり、それ以降も、この新しいセル格納構造を使ったGPUでの並列計算処理やそれ以外の関連作業に追われ、それに殆どの時間を費やして年が終わってしまった結果となった。

表計算ソフトというのは由も悪しきもセルを使って「何か」をするのが目的のソフトであるから、そのすべての基盤となるセルの格納構造を、しかもほんの少しではなく大幅に書き換えてしまうといろいろな意味で大変なことになる。勿論これほど大幅な変更をする背景にはCalcの計算処理を高速にするという目標があり、それを達成するためにこんなに汗水流して頑張るのであるが、いかんせんCalcを構成するコードの99.9%がセルの読み書きをする目的で書かれているため、いろんなところでいろんな種類の予期せぬ問題が起きる。特に格納構造が大幅に変わればそれを最も効率良く読み書きする方法も大幅に変わってしまうので、以前の構造を念頭に置いて書かれたコードが変更後にかなり遅くなってしまう、もしくは頻繁にクラッシュしてしまう、という事態にもかなり出くわした。という訳で、それらの不具合の後処理にかなりの日数を費やすはめになったのは言うまでもないのだが、幸いにも大体の部分は無事対処することができたのでとりあえず一件落着ではある。まだ未解決の部分も現在わずかに残ってはいるのであるが、それは今後少しずつ解決していく予定である。

自動スペルチェックの実装を一から書き換えるはめになったのはその後処理の例の一つで、その他にも数式の参照メカニズムの大幅書き直し、それに伴うかなりの量のユニットテストの実装などなど、とにかく沢山やった。

そんな苦労話はさておき、このセル格納構造の変更のおかげで初めて可能になった機能も多々あるので、全体的に見たら大成功だったと我ながら思っている。特にこの変更は数年前からずっとやりたいと思っていたことなので、それが実現した今、大きな肩の荷が一つ下りて正直かなりホッとしている。

SUSEからCollaboraに移る

これはもう、突然通知されて突然起こって、あっという間に移ってしまったというのが正直な感想である。なので余り考える暇もなかったし、自分にとっては選択の余地もなかったので、成るようにして成った、という結果でしょう。当時のSUSE・LibreOffice開発チームの全員が移籍したわけではないので僅かに面子が減ってしまったのは寂しいのだが、それ以外は余り変わっていないので余り移籍したという実感はない。そうは言っても、SUSEがサーバー事業に重点を置いてデスクトップ事業側には余り力を入れていなかったことはSUSE時代からも感じていたし、それに危機感を少なからず感じていたのは事実だったので、移行によってその不安が取れてLibreOfficeにより精神的に集中できる環境に移れたというのはプラスだったと言える。SUSE側も、我々の移行の際には移行が最もスムーズに進むよう最善を尽くしてくれたので、それには心から感謝したい。

ただ移行によって変更が余儀なくされた部分もある。SUSE時代は顧客からのL3サービス依頼の処理以外は結構自由だったので、L3に忙しい時期以外はアップストリームに報告されたバグの修正に費やせる時間がかなりあった。Collaboraに移った今、コンサルタントとしての開発作業に殆どの時間を費やす必要があるので、アップストリームのバグ修正に費やせる時間が以前に比べたら愕然に減ってしまったという点は大きい。それでも頑張って時間のやりくりをして、出来るだけ自分の守備範囲のバグの修正はするようにはしているが、やはり以前のようには行かない。これはもうどうしようもない。だからこれについては当面は周囲に理解してもらうという形で乗り切るしかない。

ちなみにCollaboraでは、コンサルタントによる開発業務は勿論、LibreOfficeの商用サポート業務もやっているので、LibreOfficeを導入したいけどエンタプライズ・レベルのサポートが必要、という方は、Collaboraの方をどうぞ宜しくお願いいたします。日本からは代理店を通じてのサポート契約も可能なので、最寄りの代理店にお問い合わせしてみてください。と、少し我が社の宣伝しておきます(笑)。ちなみに代理店のほうも随時募集中です。

ま、営業はこれくらいにしておいて...。

OpenCLを使った数式の並列計算処理の実装

これは２０１３年内での最も大きな変更だったと思う。先に触れたセル格納構造の変更、それ以外にも手がけた数式セルのグループ化、共有文字列(shared string)の実装、共有数式(shared formula)の実装等々かなりの大がかりな変更が相次いだのだが、それらの第一の目的は全てOpenCLによるGPUでの数式計算を可能にするためであった。

とはいえこれらの変更はOpenCLだけのために実装されたわけではなく、OpenCLを使わないユーザーにも恩恵をもたらすという点は強調しておきたい。例えば、共有文字列の実装により文字列間の等価比較が高速になり、それを使った機能は全て以前に比べて高速になることが期待できる。オートフィルタの実行速度の向上も期待できるし、それ以外にもVLOOKUPのようなセル関数も以前に比べて高速化された。一方で、共有数式の実装により、実行時のCalcのメモリ消費量の減少も期待できるし、数式セルの移動に伴う参照されたセルのアドレスの自動変更に於いても高速化が期待できる。

因みにOpenCLというのは、GPUを使って高速並列計算をハードウェアで実行する時に使うAPIで、元々米アップル社によって開発され後にKhronos Groupに引き継がれて標準化に至ったAPIである。APIの構造はOpenGLのそれにかなり近いが、OpenGLに於ける複雑な３次元描画処理の部分が含まれていない分比較的シンプルな構造になっていると言える。現在市場で出回っているGPUの殆どがOpenCLをサポートしているので、これをアプリケーション側で利用しない手はない、というわけだ。

ところでこの数式処理のGPU化の作業には、僕を含めたCollabora以外にもMultiCoreWareとAMDが加わって共同開発された。AMDはこれを機にTDFのAdvisory Boardに加わった程なので、今後もいろんな形でLibreOfficeの開発に関わっていくことが期待できる。

高橋信頼さんの逝去

最後に、日経BP社、ITPro副編集長であった高橋信頼さんの突然の逝去で２０１３年は幕を閉じた。僕と高橋さんは日本ＯＳＳ貢献者賞授賞式以来の付き合いで、ITPro掲載のLibreOffice関係のインタビュー記事の執筆の際には大変お世話になった。期間的に言ったら一年未満とそんなに長い付き合いではなかったのだけど、以前から高橋さんのOSS関連の記事には目を通していたし、インタビュー記事後もいろいろな記事で僕を引用してくれたりと、これからまた一緒に仕事できる機会がありそうで楽しみにしていた矢先のことだったのですごいショックだった。それと同時に、人生は自分たちが思っているよりも遥かに短いのだ、ということも実感させられた。

高橋さんは、記者・編集者としての腕前もさることながら、それ以外にも人の写真を撮ることに非常に長けているという印象を受けた。特にカメラの前で緊張し過ぎてぎこちない笑顔しか作れない我々にジョークを投げて自然な笑顔を引き出せるような術を持っていたのはすごいな、と思った。OSC東京の際に高橋さんの撮ったこの写真やこの写真を見るとみんなにこやかに笑っているんだけど、あれはすべて高橋さんが笑かしてくれたから、というのは今だから言える暴露話です(笑)。

高橋さん、ほんの短い間でしたが本当にありがとう。

２０１４年はどうする

という訳で、２０１３年を僕個人の視点からざっと振り返ってみた。ここで今年の目標について少し語ってみたい。

はじめの方でも少し触れたのだが、今年は特に、今までと同じことを繰り返すだけでなく、何か自分が今までやったことのない分野にどっぷり浸かる、というのを目標にしたい。特に今まで余り経験のなかったグラフィック処理について学び、そこら辺で何か面白いことができないか、と今必死に模索中である。勿論Collabora業務内に於いては今まで通りCalcが守備範囲になるのだけど、それ以外の時間では、新たな技術を学んで自分の守備範囲を広め、去年のような斬新で一見とてつもないようなアイデアを実装にまで持っていく、ということをまたやってみたいと今は密かに思っている。

LibreOfficeの発足から3ヶ月

時の経つのは早いもので、The Document Foundation (TDF)とLibreOfficeが公式に立ち上がってから3ヶ月目になる。立ち上がった直後は正直どうなることかと思ったが、実際にこの3ヶ月に経験したことを振り返って見るとやはりフォークして正解だったと思う。

OOo時代の時にはコードの改良や開発効率の向上などの案はあってもそれが提案できる環境ではなかった。コミュニティから来る提案は全てOracle勢のフィルターにかけられ、それが彼らの内部の開発陣やマネジメントからOKされなければ、いくら外部の我々の効率の向上に繋がろうとも許可は降りなかった。それどころか決定権は、常にOracle内部(というかハンブルグ開発陣内部と言った方が的確か)の限られた人間が常に握っていた。で、その意思決定のプロセスは外部には常に説明されることは無く、外部の人間にはその決定内容だけが享受される、という仕組みであった。透過性など全くあったもんでは無かった。こんな状況で、やる気のあり経験もあるハッカーが集まってくるわけがなかろう。自分もよくあんなところで3年間もよく我慢してたなぁと逆に感心さえしてしまう。Novellから給料もらって仕事としてやっていたからこそ我慢できていたからであって、そうでなければさっさと辞めていたと思う。と言うか自分は一度離れる決意をしているんだよね。その後すぐにNovellに拾われた、と言うわけだ。

前にも散々言ったと思うがOOoのコードは古くて汚いコードで充満している。STLやC++の標準化がなされる前に書かれたコードであるから変なマクロとかがそこら中にある。前々からそれらのコードをもっとSTLやBoostを使って見やすく綺麗にして、コード自体をもっとシンプルに読みやすくするのが夢であったが、上で説明したような官僚的な状態であったので、それを提案するのも億劫であった。というか提案するだけ無駄である。以前不要になったコードの一層削除を申し出たこともあったがそれすらも却下されてしまった。ひどい状態だった。それがLibreOfficeになった今、そのような理不尽な制約が取れて、意思決定も我々開発陣の手で出来る用になった。ようやく手にした自由である。

僕はコードベースというのは家のようなものである、と思っている。普段は多少散らかっているかもしれないが、人が訪ねて来る度にある程度綺麗にする。これは常識である。ここで言う訪問者というのがハッカーであって、新しいハッカーを寄せ集めるためにはまずコードベースを綺麗にしておく必要がある。そうでなければ誰も来たがらない。これもまた常識である。でも住んでる人間にとってはもうその散らかった状態に慣れてしまっているので、どんなに散らかっていてもあまり気にならない。そんな環境に何十年も住んでいると、もう綺麗にするという必要性さえ全く感じなくなってしまう。それどころか誰かが綺麗にしようとすると、それに反発さえしてしまう。だから最終的には誰も寄ってこなくなる。

LibreOfficeになってから、やっとコードベースの大掃除が出来るようになった。とはいえうちらもバグの修復や機能の実装などもしなくはならないので、四六時中コードの整理整頓ばかりはしてられないのだが、幸いにも同じような考えを持つ有志達が現れたお陰で結構なペースでclean upの作業は進んでいる。この3ヶ月の間だけでもLibreOfficeのコードは大分綺麗になったくらいだから、1年後にどのくらい綺麗になってるかは想像すらできない。以前とは雲泥の差である。コードを綺麗にすると、なぜか作業効率が上がったような錯覚に陥る。いや、それは錯覚ではなく事実なのかもしれないが、いずれにせよ気分は良い。この点だけでもLibreOfficeが出来た甲斐があると思う。

ただLibreOfficeになってから大変になった部分もある。インフラはもはやOracleの提供するものには頼れないので自分達で調達する必要がある。LibreOfficeのような大規模なプロジェクトの場合は特にそれに一苦労する。でもふたを開けてみたらなんとかなるものである。GitレポジトリやBugzilla等は、Go-OO時代からお世話になっているFreeDesktop.orgのを使い、ダウンロードのミラーはMirrorbrainにお願いし、メーリングリストとウェブサイトだけをTDFでなんとかする、という手筈になった。で、それらを運営できるだけの資金がありがたいことに集まってきたようなので、取り敢えずは安泰である。

全体的に見て、とりあえずLibreOfficeは良いスタートを切ったと言いきれるだろう。この勢いを止めることなく、LibreOfficeのために自分の出来る限りのことをとことんやり続けるのが自分の今の目標である。

FacebookやmixiでLibreOffice

LibreOfficeの日本語用ファン・ページをfacebookで作ってみた。
http://www.facebook.com/home.php#!/pages/LibreOffice-ri-ben-yu/162804050405413

で、mixiでもLibreOfficeのコミュを作ってみた。
http://mixi.jp/view_community.pl?id=5298956

興味のある人は参加されたし。両方ともまだ閑古鳥状態だからねぇ...(苦笑)。

LibreOffice by The Document Foundation

http://www.documentfoundation.org/

という訳で、やっとの事で公開までこぎつけました。これが何かと言うと、LibreOfficeの前身であるOpenOffice.orgからの派生で、元々OOoのコミュニティメンバーだった人達によって設立されました。うちらNovellもその一員に加わっています。このプロジェクトは成るようにして成った，という感じですね。まぁ僕に言わせれば10年遅かったという気がします。ただ派生とは言ってもある意味ではOracle版のOOoの方が従来のコミュニティ・ベースの形式から遠ざかって行ってしまったので、うちらから言わせれば向こうの方が派生版なんですけどね。

このプロジェクトの目的は、一つの企業(つまりOracle)に依存しない、開発者が中心となった、健全で非官僚主義的なコミュニティの育成を第一にしています。これは今までSunやOracleの手では成し遂げられなかったものです。でも健全なオープン・ソースプロジェクトを育成するにはここから出発しなければなりません。

で、当面は、Go-OOのコードが基盤となってその上に新しいものを構築していく予定です。Go-OOはLibreOfficeによって取って代わることになるので、その名前は徐々に消えていくことになるかと思います。

最後に、このプロジェクトが成功するか失敗するかは全てコミュニティの手にかかっています。応援のほどよろしくお願いいたします。手を貸してくれる方は大歓迎です。

OSC Tokyoの感想

9月の始めに東京に出張だったわけだが、ちょうどいい時期に立川でOpen Source Conference (OSC) Tokyoが開催されてたので、出張期間を1日延長して初日・金曜日だけですが顔を出してみました。で、その時の感想を幾つか。

まず、Novellがゴールド・スポンサーになってた、のはいいのですがNovellの東京支社からは誰も来てなかった。東京支社の誰かと会えると楽しみにしていたのですがこれは誤算。あのMicrosoftだってブース出してたのに...。東京支社の人とは同じNovellとはいえ余り一緒に仕事をする機会はないので殆ど交流が無いのがちょっと悲しい。

ホテルが一緒だった会津若松市の目黒さんと会場まで同行して、MeeGoや他の自治体でのOSSの使用状況の講演に出席。で、最終的に目黒さん自身の講演も拝聴しました。あと、OOoのサポートを有償で提供するアシストの小川さんという方と少しおしゃべり。そこで思ったのは、日本ではまだまだOSSはそれを使ってコスト削減、という側面が重視されていて、開発コストの共有，という側面まではまだまだ浸透していない、ということ。この状況が将来的にどう発展するかに興味が沸く。まず始めの一歩は有償でサポートを提供する会社がどれだけ一般的になるか、という面である。それが一般的になれば、次のステップとして有償の開発サポートも実現可能になるであろう。OOoに関して言えば、ユーザー側はとりあえずバグを報告してそれを開発をスポンサーしてくれている企業に「直してね」とお願いする図式に現在ではなっているのであるが、これは長い目で見たら長続きはしないであろう。というのもバグを一つ直すのにも開発費がどこかで発生して、誰かがそれを支払わなくてはならないからである。将来的にはせめてパッチをバグ報告後に上げられるような状況を日本の市場でも持っていけるようになるよう切に願う。で、もっと将来的にはコア開発に参加出来るような人材を育てられると一番よい。つまりパッチ書いてあとはよろしく、ではなく最後にintegrateされるまで見届けられる人たちの育成である。僕自身はそれくらいは日本でも可能であると思うのだが、どうでしょう。

まぁそうはいっても現在のOracle中心の開発形態は、Oracle企業自体がかなりの秘密主義であるために、外部の人間の開発への参加は本当に限られたレベルでしか出来ないのが現状である。これをうちらGo-OO陣営は直そうとしているのだが、まぁ現在のユーザーの視点から見たら(とりあえず誰かが開発して無料で使えさえすれば)全く関係の無い話なんだろうな、ということは想像が出来た。悲しいがこれが現実であろう。ただ将来的にコア開発出来る人を育成するにはこの点を直さないとダメである。それは確実に言える。

あと、オフィス・スイートに関して言えば、ユーザーの必要としてる機能のレベルは日本ではかなり低いものだというのもわかった。つまり、はっきり言ってしまえばOOoの今の機能でもそばで教えてくれる人が居さえすれば十分使える、という点である。ということはだ、仮に明日Oracleが開発から手を引いたとしても、バグさえ直してくれる人達が取りあえず数人居てくれればしばらくは安泰、ということになる(のかな？)

そうそうopenSUSEのブースにも立ち寄って見た。渡辺さんという方がブース番をしていた。openSUSEについていろいろとお話をした。松本さんにも会えるかな，と思ったけど無理みたいだった(笑)。

ちなみに、以前同僚のCedric Bosdonnatから名前だけは耳にしていたフランス人のJean-Christophe Helaryさんとも顔を会わせることが出来た。日本語がかなり上手かったのがすごかった。もうネイティブであるアレは。日本はもう15年目だってさ。

とまあこんなところでしょう。日本は生ビールが美味しかったです。あと明星大学の学食は安くて美味しかった。結構日本の大学の学食というのは侮れない。そのうち学食ツアーとか企画してみるのも面白いかも(笑)。

レガシーコード

吉岡氏のブログは常に目を通しているが、以下のブログ

http://d.hatena.ne.jp/hyoshiok/20100403

は得に目についた。僕自身も激しく共感する内容である。で、こんなのを読むとOOoのコードベースがいかにレガシーで、いかに危険でいかに未来がないかがわかる。

テストのないコードは危険である。だが多くの開発プロジェクトはテストが書かれること無く開発が進められている。中にはOOoのような大規模なプ ロジェクトもこれに含まれる。一応VCLTestToolという、OOoの機能を一通りチェックするテストは存在するが、それは「統合テスト」であって 「単体テスト」ではない。で、統合テストというのはないよりはマシであるが、それ以上でもそれ以下でもない。

テストのない大規模なプロジェクトに長年関わってると、それが当たり前になってしまい、テストを書くというくせが出来ないしテストを走らせるとい うこともしない。だから、コードを書くときもテストが書きにくいような書き方をする。OOoはそのようなコードで充満されている。救いようがない。だから 1から始める必要がある。

ちなみにそのようなレガシーコードにいざ単体テストを設置しようとしても、莫大な労力を必要とし、しかも他の開発陣がそれを意識せずテストできな いコードをどんどん増やしていくと、無駄な努力となる。なのでそのようなコードを蘇生させるには、テスト・ハーネスが設置されるまで新しいコードがチェックインされるのを全て廃止する必要がある。大抵のプロジェクトの場合はそんなのは不可能なので、フォークする必要があるという訳だ。

ちなみに、この吉岡氏が使っている本の引用をよく見ると、僕が持ってる本の一冊によーく似ている。と思ったら、実はその本の日本語訳みたいである(笑)。

ちなみに僕の持ってるのは

Working Effectively with Legacy Code, by Michael C. Feathers

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

で、SlickEdit時代に買った本。OOoの開発にも恐ろしいほど当てはまる、読んでて笑えてくる(でも半分涙目)本である。

Calcの行数を....

Calcの行数を、要望に答えて65536行から1048576行に増やしてみたら、Calcのコード内で遅い部分が次から次へと面白いように暴露されてくる。いわゆる performance bottleneck っていうやつね、英語で言うと。

もう既に３つくらいその遅い部分は直したけどね。でもまだまだ出てくるんだろうなぁ...。

といってるうちにもう一つ見つけたよ。