openSUSE + LibreOffice virtual conference 2020参加の感想（その２：技術・実装）
表題のイベントの感想、その２。今回は技術・実装編。
繰り返しますが、「イベントレポート」ではなく、つまり各トークの内容を紹介するものではなく、 背景とか前提とか、 聞きながら私が思ったり感じたりしたことを書き出す……というのが、この記事の趣旨です。 ちゃんと内容知りたい方は動画・資料の公開待った方がいいと思いまする。
この記事は全３回予定です。
- その１：LibreOfficeプロジェクトとコミュニティ
- その２：技術・実装
- その３：移行など・その３：その他（openSUSE関係、全体の感想）
ワークショップなど
How to debug Writer, forwards and backwards / by Michael Stahl / 2020 October 16 - 16:00
これめちゃんこよかったです！
Writerの、けっこうめんどくさいバグを解析する様子をscreencastで録画したやつに、 解説の音声をかぶせたビデオをみんなで見つつ、チャット欄で質問してMichaelが答えてくれるという趣向。
とはいえ私LibOの開発もLinux上のデバッグもWriterの実装もあんまり把握してないので、ここで共有されていた知見の半分も理解できていた自信がない。皆さんは追って公開されるであろうビデオを参照ください。ここでは軽く箇条書き。
- 追ってた問題はこれ。Bug 134253 - CRASH: undoing field paste
- ちょっと複雑なWriter文書をCtrl-Aで全選択して、Ctrl-Cでコピーして、再度ペーストして（クリップボードの内容にあるもとと同じ内容で上書きされることになる）、それをUndoするとクラッシュするという問題
- 使っていたのはrr。gdbのPythonによるフロントエンド。
- rrにはrcってコマンドがあってreverse continue。死んだところから逆再生をしてくれる（？）。ほかにも逆ステップ実行とかあって猛烈に強力。
- rrはIntel CPUでしか動かなかったけどちょっと前にAMD CPUで動くパッチがマージされたので今は動くかも、とのこと。ちょっと不安定なこともあってrcしたりすると死んだりもするけど、動けばめちゃくちゃ強力なので使いましょうと
- QAチームのXiscoが「デバッグにかかる前に再現データ小さくしたりしないの？」と質問したところ、「順実行と逆実行、あと条件付きブレークポイントを駆使してポイントを絞っていくほうが早い」とのMichaelの言
- rr上での配列やリストの表示は最大表示個数を設定できるんだけど、表示個数10000とかにしちゃって、rrのログ機能をONにしといてそのログをテキストエディタで開いてそっちで確認するとなると、文書オブジェクトみたいなデカい構造オブジェクトを見やすくなる
- 今回の場合はUndoの前後でノードが消えてて？位置がずれてて？、それを知らないやつが元のノードを参照しようとして落ちてたというのが表層的に起きてたこと
- その現象をもとに怪しいコードを順逆実行などで詰めていく
- 怪しい場所を見つけたら
git log -pで差分を追いかけるとそのコードがどのコミットで（どういう意図で）入ったか確認できる
とにかく非常に面白かったのですがこっちの理解がおぼつかない＆くそ眠かったので、ビデオ公開されたらまた見直したいです。チャット欄も何とかして保全されてねーかな、あれも後で参照したい……。
あとこういうの見ちゃうとやっぱWindowsじゃなくてLinux上で開発したくなりますね。Visual Studioじゃこんなに柔軟なデバッグできないよ、ね……？
LibreOffice Virtual Hackfest / by Ilmari Lauhakangas / 2020 October 17 - 14:00
担当のIlmariはTDFの「開発マーケティング」担当で、要は新しい開発者に対するメンタリングをしたり、 開発やQAで活発に活動してる人を一本釣りして「こういう活動してみない？」って言ったり、 そういう役割の人。ちょういい人でもあります。 本人はC++あんまりできないことを気にしてるらしいと聞いたことがあるけど、どの言語が書けるとか書けないとかではなく、メンターとして優れてると思います。
で、通常LibOConはHackNightっていう合同ハックイベントをやるんですけど、 今年はできないので、1時間のワークショップをしましょうと。で、これもまた非常によかった。
これも箇条書きで。
- お題は「bibisect」「バグのトリアージ方法について」「ヘルプの作成について」「その他質疑応答」
- bibisectは「binary bisect」ってことで、要はLibOのデイリービルドをGitリポジトリに突っ込んだものがあって、それを用いてgit bisectして「どのデイリービルドで不具合が混入したか」を調べること
- bibisectのやり方を説明するビデオを作ってくれたのでみんなでそれを見ました。このビデオ非常に分かりやすくてよかった。あとで↑のWikiにも貼るよ、とのことでした
- ついでバグトリアージ。つまり誰かが起票されたバグをチェックして、その先開発者が解決に取り組めるような状態にすること
- トリアージの最初はまず重複（dup）を見る。同じバグを別の人が報告してないか
- タイトルや詳細説明を見て、象徴的な単語を拾って検索して探す。同義語なんかも考慮する
- 見つからない場合はOPEN以外のステータス、あるいはResolutionをすべて
---にするなど - あるいはうんと単語数を絞って、後ろから（最近出たバグから）順にみていくのも効果的
- DUPの場合はそれぞれのバグを見比べて「より良い」方を残す。「良い」というのは、条件を不要に限定しすぎていないってことも見る
- 例えば「サイドバーでこんな不具合がある」という報告であったとき、別の報告で「メニューバーでもサイドバーでも不具合がある」とあったら、そっちのほうが条件が広いので
- DUPとして落とすべきバグ票は、Whiteboardがあったら消して「Status」を「RESOLVED/DUPLICATE」にして、残すべきバグ票の番号を記載して閉じる
- 昔は動いてたんだけど……というたぐいのバグはキーワードにregressionとbibisectRequestedをつけておく。bibisectはあとで自分でやってもいいし、このキーワードついてたら誰かやってくれるかも
- あとBugzillaのAdvanced Searchのコツをいくつか紹介してもらいましたが、この手のノウハウはBZ使ってる他のOSSプロジェクトとも共有できそうな気がします
- お次はヘルプ。LibOのヘルプはXHPという形式で書かれてます。
- XHPのオーサリングには専用のオンラインエディタ LibreOffice Documentation XHP Editor があるので使おう、構文チェックとかできて便利。CLIでgit触らなくてもコミットできます
- 基本的な情報はWikiにある。入り口 -> XHPの文法など
- LibOのソース検索システム opengrok を使って既存のヘルプを検索するのもいい
- 最後に質疑応答
- Q: 直したい問題があったときにコードのポインタをどうやって知ればいい？
- A: opengrok でももちろん良いが、ローカルにコードがあるなら git grep するのが早い
- コメント: 似たような問題を git log で探して、その修正コミットを参照するのもよい
なおバグトリアージについては、イベントでメンターしてほしかったらタイムゾーン的に無理がない範囲でやるから連絡ちょうだいね、というIlmariのメッセージがありました。
Implementation Detail / by Stephan Bergmann / 2020 October 16 - 15:00
全然ワークショップじゃないのだけどLibreOfficeの特定のコンポーネントについての話ではないのでここで紹介。新しいC++で入った言語機能と、それをLibOのコードでどう使えるかって話。
Stephenは毎年、LibOConではこの手の話をしてくれて、門外漢にもとても分かりやすいし面白くて非常に楽しみです。むしろファンだと言ってもいい。
ここも理解おぼつかないので箇条書きでごまかす。
- 今のLibOは基本C++17。structured bindingとか色々使えます
- ただしC++20、C++23対応を進めて行ってるよというステージらしい
- ちょっと横入ですが、私の理解するところでは、LibreOfficeのC++バージョンはしばしばツールチェーンのサポート状況で決まります。 Linuxはだいたい問題ないのですが、Visual Studio（MSVC++）とXcodeがですね。 前者は今のmasterはllvmでビルドするようになったからあんまり問題ないのかしら。後者は「Old ｍacOSで実行可能なバイナリは古いXcodeでしか生成できない」問題がありますね。 なので古いmacOSをサポートから落とさないとコンパイラのバージョンも上げられない。
- さらに横道ですが前提として cpprefjp - C++日本語リファレンス でC++の各標準間の新機能をおさえてからこのトークに臨めばよかったなーとちょっと後悔
- すごい雑駁な理解だと C++20 だとコンパイル時評価がさらに進んだのでそれを使うと記述スッキリできるしいろいろよいよという話
- 例として挙げられていたのはLibOの文字列を表現するクラス
OUStringとそのリテラルOUStringLiteral OUStringは内部的にはrtl_uStringへのポインタで、rtl_uStringは参照カウンタと文字数（？バイト数？どっちだろ）とNUL終端の文字列ががっちゃんこしたもの- こいつのリテラルからの生成をコンパイル時評価使うといいよ、みたいな話だった気がする
- 一見for文でループぐるぐる回りながら値をコピーしてるっぽいコードがコンパイル時評価で実はループ回してるわけじゃないんだよ（きもっ）とか
- さらに
constevalでstd::copy_n()が使えるようになりさらに可読性アップ……とか、そんな話だったと思うのだけど、間違えてたらすみません - 質問で「それビルド遅くならない？」「なるねえ」みたいな話がありました。LibOのビルド、いまでも十分遅いからな……
Google Summer of Code 2020 Panel / 2020 October 16 - 14:30
GSoCの成果発表。残念ながら前と後ろが押して、Yusuf Ketenさんの、拡張機能を追加するためのダイアログAdditions Dialogだけ聞きました。
いままで拡張機能って専用の差異とに行って *.oxt 入手してそれをLibOの拡張機能マネージャーで開いて追加する……って、かなりめんどくさい手順だったのが、
今回はLibOから直接ダイアログ開いて追加できる……これはすばらしいですね。次期メジャーリリース 7.1 で入るみたいです。
LibOコア関係
Implementing Vulkan-capable drawing using the Skia library / by Luboš Luňák / 2020 October 15 - 14:00
7.0のリリースノートにさりげなく書いてあるこの一文：
この説明をするトークです。実は私はSkiaとVulkanの関係性も理解してないぐらい、この件よくわかってなかったので、ちょうどよいなーと。
- LibOのウィジェット描画抽象化レイヤとしてはこれまでVCL（Visual Class Library）があって
- このVCLのバックエンドに各プラットフォーム別の実装がある
- VCL自体1990年から使われておりいろいろつらみが
- 俺たちはオフィスソフトの開発者であってグラフィックライブラリの開発者じゃねーんだよ
- より広く使われており信頼性の高いライブラリを用いてVCLの層を薄くしたい
- そこでSkia。GoogleがChromeのために開発した2Dグラフィックライブラリ
- Skia自身にいくつかのバックエンド実装があって、その中でGPUを用いるものがVulkan
- ほかにもCPUで頑張るやつや、OpenGLを用いる実装なんかもあるそうな
- ということでVCLのバックエンドとしてSkiaを用いるようにして、Windowsでは（元々のOpenGLを自分たちで叩く実装の代わりに）それを標準にしたよ、というのが現状
- VCLは設計が古いためI/Fも古く、1bppやパレット付きビットマップなどSkiaでは直接提供されていないものを扱う必要があるため、そこは適切に変換する
- グラフィック操作をVCLに任せるのではなくよりハイレイヤー（LibOのコード内）で行っている場合があり、そういう部分を対応する必要があった
- ただしOpenGL化のときにある程度は見直せており、その成果がある程度は使えた
- パフォーマンス。Linuxにおいて、Raster Skia（Vulkanではなく）であっても、非Skia（X11）では非常に高速になった
- デモを見ると確かに非常に速い
- 疑問）7.0ではいくつかCJKのレンダリングがおかしくなったという問題があるらしくSkiaをオフにすると直るという話だが、今回の説明だとVCLのバックエンドを差し替えただけなのでそういう問題が起きるというのは若干考えにくい。途中コメントがあったハイレイヤーとの不適切な責務分担のせいかな……？
OOXML / PDF Digital Signing in Draw and elsewhere / by Miklos Vajna / 2020 October 16 - 11:30
コロナ禍で注目されている文書の電子署名に関するLibOの機能について。
- ODF署名：OOoのころからある機能。だいぶ古い。GPG署名とは別の機能
- OOXML署名は、名前の通りMS OfficeがOOXMLに対して署名する機能の互換性のために導入。なぜか署名情報に画面解像度とかOSバージョンとかの情報が露出する
- PDF署名はもちろんPDFの仕様にのっとった署名だが、LibOが持つ三つのPDFパーサーは全部これが解釈できない（Popplerベース、PDFium、Hybrid PDFのためのもの）ので、さらにもう一個実装が必要
- multiple signaturesは証明書チェーンの検証が必要でちょっと面倒
- PDFの仕様以外に、アプリケーションとしてのAcrobatと動作を合わせないといけない部分がありつらかった
- 意味が分からないなりに目盛ったキーワード：XML-DSig（昔LibOConで聞いた記憶がある）、DocuSign （https://www.docusign.jp/ だよね）、libxmlsec（実装で使ってるらしい）
ここ注目度が高い技術なのと、私の本業にも近いのでもう少しちゃんと勉強しないとなと思った次第でございました……。
LibreOffice Online / Collabora Office mobile関係
Making Online trivial to setup / by Muhammet Kara / 2020 October 15 - 15:30
トルコのLibO開発者Muhammet Karaさん。トルコ国内でHackFestを実施したり、若手技術者育成なんかにも力を注いでるナイスガイです*1。
さておき、LibreOfficeをブラウザベースで使えるLibreOffice Online（通称LOOL）。あるいはそのCollaboraブランドCollabora Online（COOL）。便利ですが構築はやや大変でした。 商用利用ならコストかけて真面目に構築してもいいけど、個人用にひょいっと立てるには若干ハードルが高かったのも事実。
それが、なんとなんと、OSSのDropboxクローンであるNextcloud*2のアプリ（プラグイン的なもの）である「Collabora Online」
を使うと、NextcloudのWeb UIからワンクリックで（COOLが）インストールできるようになっちゃったんですね*3。その技術解説。
……なんですけど、このときすでにだいぶ眠くってね……あんまりちゃんと聞き取れませんでした。以下「たぶん」って内容を箇条書き。
- ワンクリックで入るCOOLはAppImage化されたもの
- 通常LOOL/COOLとクライアントアプリはWebSocketで（WOPIというプロトコルを用いて）しゃべるのだけどAppImageだとWebSocketがしゃべれない（……んだと、思う）
- なのでPHPでプロキシプロセスを立てて、WSじゃなくてHTTPSで通信してる
- HTTPSだとWSでつなぎっぱなしにしてバイナリなプロトコルでやり取りするのにくらべ、TLSのセッション確立およびHTTPヘッダの分下駄を履いてしまうのでパフォーマンスがつらい
- なので可能な限りセッションを維持する工夫をしている
- 一部ではどうしてもポーリングしないといけないところがあり（理由失念）、そのチューニングも頑張っている
ちょっと理解おぼつかなかったところもあるので、こいつも資料後で読み返すなりして復習したいです。 スライドに丁寧に参考文献が挙げてあったと記憶してるので。
History of Online & Mobile / by Jan Holesovsky / 2020 October 17 - 12:00
KendyことJan Holesovsky氏の発表は名前の通り、主にCollaboraが今注力してるオンラインとモバイルの歴史について。
- 2011～2012年の時点でSUSE社内でAndroidでLibOを動かすという実験プロジェクトがあった。「まあ動く」程度のものはできたが、死ぬほど遅いとかデバッグが人類には不可能とかいろいろあった
- 大きな転機は2013年、CloudOnという会社が「OOXMLのiOSビューアのエンジンとして」LibOを使いたいという要求があって、そのために（SUSEから離れたメンバーが創設したばかりの）Collabora Productivityが協力することに
- この時生まれたのがLibreOfficeKit（LOKit）、LibOのエンジンを直接キックするC/C++のライブラリ
- メモリ制約が厳しいモバイルOSのために「タイルレンダリング」が導入される。つまりLibOの文書のレンダリング結果をビットマップタイルにして得るという方法
- これであれば画面に表示される部分のタイルだけを扱えばよくなりメモリ使用量が大幅に削減される
- ここ、私の歴史認識が違って、てっきりLOOLが先にあって、LOOLのために作ったタイルレンダリングをモバイルでも使うよという話だったのかと思ってたけど逆なんですね
- CloudOnのアプリは確かクローズドベータは出て、公開ベータするよってなったところでDropBoxに会社ごと買われてしまいました。多分まるごとPapersのチームに吸収されたんだと思います
- CloudOnが買収されなかった未来はどうなってたんでしょうねえ……歴史にでもしかはありませんが
- で、この2015年にIceWarpという会社の投資を受けてLOOLの開発スタート、このときにLOKitで作ったタイルをLeafletで並べて描画するという基礎ができる
- なぜだか知らないけどLibOにはクラウドやモバイルが存在する前からmultiple view機能というものが存在して（正直、使い道不明……）、そいつがLOOLの共同編集に使えた
- LOOLは共同で使うアプリなので設定ダイアログも複数人が設定いじることを考えなければならず、当然LibOのコアはそんな考慮されてないのでいろいろつぶしていった、ここらへんは過去のLibOConでいろいろ発表がありました
- そして2019年、Adfinis SyGroup AGの投資を受けてCollabora Officeのモバイル版開発がスタート、去年のLibOConでも発表があったとおり「アプリのサブプロセスとしてLOOLサーバーを動かして、アプリの実体はWebViewでLOOLのUIを出す」という実装
- モバイルだとタッチ主導UIである必要があるが、それを担うのが「サイドバー」。デスクトップ版と見た目異なるが提供するものは一緒。この点については今年Bringing the Sidebars Online という発表があったのでそっち参照
- モバイルで必要なUIをすべて実現するにはUNO APIだけだと足りず、一部は（エンドツーエンドテスト用の）untest APIを使って実現したとか
- 今後はleaflet/poco依存を減らしたいなどと言っていたのがちょっと気になりますね
技術的にめっちゃ踏み込んでるわけじゃなくて歴史をさらったお話なのでわたくしのような薄い人間にもわかりやすくてよかったです（小学生みたいな感想）。
Online – Improving visual consistency / by Pedro Silva / 2020 October 17 - 13:00
これはですね……うーん、ちょっと思っていた内容と違いました。自分的に面白いと思ったところだけ：
- Pedro Silva氏はCollaboraのデザイナーさん。デザイナーさんだけあってスライドのデザインはカッチョよかった
- 肝心の「Visual consistencyとはなんぞや」みたいなことは実はいまいち理解できなかったけど、いろんなトピックがあるみたい
- 例えばCSS。Consistentyを保つためにはファイルをまたいで冗長な部分があってはいけない（全体を統一的に直したいときに、一部コピペされたところが直ってなかったとかつらい）とか、特定解像度を仮定したコーディングがあったらだめだとか
- 徹底するために https://stylelint.io/ でlint。きちんと除外ルールを整備。それで
make runするたびにチェックする仕組みを作る。すばらしい - 使い勝手がよいだけではなく実装もきれいになっていることが大事。これ開発とUI/UX設計の距離が近くないと難しいよね
- Collabora Office for Mobileでは可能だろうけど、LibOの開発にこういうやり方ができるかというとどうなんだろ。どういうやり方があるんだろ
- 後半はどっちかというとメタな考え方の話で正直聞いてて眠かったです……あとCOOLの宣伝が長い……
- 「モバイルアプリなのに保存アイコンがフロッピーなのはvisual consistentなの？」みたいな質問が出て、なんかいろいろ長々と答えてたけど、どうにも言い訳してるようにしか聞こえなかったのが若干残念（私のヒアリング能力のせいで、ちゃんと答えてた可能性はあります）。フロッピーはダメだとしたらどういうものが保存を意味するのにふさわしいかって考えが知りたかった
- アプリによっては右上にチェックマークってやつもあるけどアレもあんまりわかりやすくないよね身たいな話はあったようななかったような
- 保存なんて考えるのは平成までだよねー、自動保存が当然じゃない？って考えもありえるのかなあ……
Improvements to PDF support in Collabora Online / by Tomaž Vajngerl / 2020 October 16 - 18:00
LOOL / COOLでPDFインポートを強化したよというタイトル通りのお話。
- DrawのPDFインポート機能はPopplerベース。インポートしたものが編集可能になるというのはメリットだけど、一方で正確性に難がある。応用によっては編集可能性よりも正確さが嬉しいこともある
- そんなわけで正確性を重んじて、挿入されたPDF画像の処理はPDFiumという別のライブラリ（Chrome/Chromiumが使っている奴）を用いるようにしている
- この件については2018年のLibOConで発表があったのでそれを見るか、解説したブログ記事を読みましょう
- LOOL/COOLではDrawは機能としてないので、PDFインポートはビューアとしての機能になり、基本PDFiumを用いてるけど、単なるビューアとしても機能は必要でそれを追加したという話
- 足りない機能というのは、検索機能と注釈（annotation）機能
- 検索については、PDFiumの内部オブジェクトはレンダリング後のグラフィックオブジェクト以外にPDF自体をメモリ上に持ってるのでそれを使って検索できる
- 検索結果の位置を矩形で取り出すAPIも生えているので、それを用いて結果表示可能
- PDFの注釈機能はテキストだけじゃなくていろんなものにつけられるけどまずはテキストへの注釈を実装し、そのあと描画オブジェクトにも実装……とか言ってた気がする
- ここらへんでメモがぷっつりと切れてました……
Open Document Format (ODF)
ODFは言わずと知れたLibreOfficeのネイティブフォーマット。詳しくは過去に記事書いた*4 のでよかったらそちらを参照してください。
ODF state of the union - ODF 1.3 ante portas / by Thorsten Behrens / 2020 October 15 - 15:00
ODF 1.3はOASISの委員会勧告になって今ISO/IEC標準化を目指してるけど、そういう現状が聞けるかなというトーク。 ただ、このときJitsi meet bombをくらって発表がめっちゃ大変そうで、私もそっちに気を取られてあんまり聞けてないですね……。
なので一点だけ。ODF 1.3に続いてODF Nextという取り組みが始まってるんだけど、 そっちでは標準の編集そのものをCI化する（実はぴんと来てないけどODFの標準は文書で記載された定義とXMLのスキーマとの両方なので後者のことを言ってるのかな） 、 メールベースの議論ではなくGitHubに持っていく、とかそういう取り組みが話されていて、技術で解決できる物事は技術で解決して、 標準策定までのリードタイムを短縮しようという試みはよいなと思いました*5。
ODFについては、Svante Schubert氏の：
という発表もあって、聞きに行った記録は残ってるんだけど内容についてまったく残ってない……どういうことだ自分。ごめんなさい。 お詫びにODF ToolkitのURL貼っておきますので関心のある人はどぞ。
マクロ・機能拡張・その他
« LibreOffice Python scripting made simple w/ IDE_utils » - Dev/Doc tracks / by Alain Romedenne / 2020 October 17 - 10:00
@LibreOfficiant ことAlainさんによるLibreOfficeのPythonによるマクロ開発のセッション。
ASPOっていうLibreOfficeのPythonマクロ統合開発環境の説明が興味深かったですね。
こいつについては去年のLibOConでも @LibreOfficiant さんのトークで名前知ってたんですが、 LibOのBasicの開発環境程度なんじゃないの？ と勝手な偏見を持ってあんまりちゃんとチェックしてなかったんですよね。 でもビルトインされたPython consoleでLibOの内部コンテキストと同じ状態を作っていろいろ試せたりするみたいで、 なんというかJavaデコーディングするときにもIntellij IDEAでブレークポイントで止めた状態でインスペクタでコード片を書いて動きを確認つつコードを書いてる私には、 結構いいかも……と思いました。
LibOのPythonマクロもずっと宿題なので、今度真面目に触ってみますかね。
LibreOffice Document Encryption API / by Vasily Melenchuk / 2020 October 17 - 12:30
機密性を保って文書交換したい場合、PPAPはイヤですよね。かといってLibOの機能でパスワードロックかけたとしても、パスワードは人類に使いこなすのは難しすぎるのです。 強度も弱いし、パスワード漏洩しちゃうと無力だし、あれこれ……。
なのでCMISとかNextcloudとかGoogle Driveとかの機能を使いたいねとなるわけですが、そんなあなたにRights Management Services = RMS*6。
そのRMSの対応をする拡張機能を作ったよという話っぽいです。 モチベーションとしてはRMSでロックされたOOXMLを読めるようになりたいという。 MSの仕様をもとに暗号化された文書を解釈できるようにして、 実装上はUNOのXPackageEncryptionインターフェースを拡張する……みたいな話に聞こえました（雑）。
Windowsでしか動かないけどサンプルの拡張機能ここにあるそうです。興味がある人はどぞ。
Windowsでしか動かないのはMSがSDKをWindowsでしかリリースしてないから？という質問に対して、いやマルチプラットフォームで存在するはず、と答えてましたが、 じゃあなんでWindowsでしか動かないんだろう……ソース見ろって？
Remotely accessing files in a distributed LDAP+Samba-based infrastructure / by Marco Marinello / 2020 October 17 - 10:30
イタリアで複数の学校をつないで、各学校に所属する人たちが、公衆網から接続して安全に自分の学校のSambaファイルサーバーにアクセスできる仕組みをつくったよ……という話らしいです。 FUSSプロジェクトというGNO/Linuxベースのシステムの一環らしい。イタリア語読めないですが……。
クラウドサービスでも使えばいいのになんでこういうの独自に実装するのというと、それはやっぱりGDPR的というか、自分たちの情報は自分たちでセルフホストしないとってことらしい。 ヨーロッパはここら辺やっぱセンシティブなんですねえ。
それはともかく発表者のMarco Marinello氏はなんと19歳！ 19歳でこんなプロジェクトにかかわって国際イベントで登壇してるんだ。すごいな。
LibreOffice AppImages: Past, present and future / by Simon Peter, Antonio Faccioli / 2020 October 16 - 19:00
AppImageはLinuxにおけるパッケージングシステムの一つで、普通に単独のファイルとして配布されてて、手元に持ってきて実行権限つけるだけで実行可能になるというもの。 特にQA作業で古いバージョンをちょっと動かしたいみたいなときに超便利です。
で、私は単にAppImageの単なるユーザーだったんで中身のことはさっぱり知らんのですけど、このプレゼンでそこらへん説明があったので資料公開されたらもっかい読もうっていうのと、
ここにAppImage版LibOのビルドスクリプトがあるので眺めてみようと思います。
近々の機能としてはAppImageに閉じ込められたLibOをアップデートする機能、しかもGUIの「更新を確認」が機能するというのはなかなかよいなと。 古いバージョン塩漬けじゃなくて、AppImageで最新追いかけたいってニーズもあるかもわかんないですからね。
それと最後に、FreeBSDの上でLinux版AppImageが普通に動いてるという驚きのスクショが公開されてビビりました。そんなことできるんだ……すごいな。
……ということで
その２、終わりです。最後は力尽きて駆け足になってしまいました。というか十分すぎるほど長いですしね、この記事……。
つづきはその３です。今日拾えなかったトピックをまとめて。ではまた。
*1:関係ないけど彼と私と榎さんで飲んだときに、「いやー日本人面白いなー」ってやたら言ってもらったのを覚えてます。いや、たぶん私（や榎さん）は典型的な日本人じゃないよ……。
*3:Nextcloudのオフィス文書共同編集ソリューションにはOnlyOfficeというやつもあり、こっちはPure JavaScript実装なのでサーバー側の手当てが不要で、その手軽さで好まれたりしてて、巻き返しのために簡単インストールが必要だったんじゃないかな……と、想像。
*4:関係ないけど、編集可能なリッチテキストを表現するフォーマットとして、正しい意味で「国際標準」であるものとしては唯一のものであるODFを、イギリスや台湾に倣って日本でも政府が用いる標準フォーマットにしましょうという提案が、デジタル改革アイデアボックスに出ています（その１・その２）。よろしければぜひ、「賛成」をポチっとしてください。
*5:アプリケーションの都合でどんどん仕様追加されているのに、標準側は本質的でないTypo修正しかしてないどっかの標準に爪の垢を煎じて飲ませたいですね。
*6:ここらへん参照でしょうか： RMS の動作のしくみ | Microsoft Docs
openSUSE + LibreOffice virtual conference 2020参加の感想（その１：LibreOfficeプロジェクト・コミュニティ）
そんなわけで予告したとおり、表題のイベント参加してきましたよ。通称oSLO。
参加したセッションの感想とかなんとかをまとめておきます。 時系列でみても退屈かなと思うので、テーマ別で。
なお、オンラインイベントということもあって、 あとから資料もビデオも公開されるでしょうし、 わたしみたいに大して英語ができない人間ががんばって聞いて内容を要約して公開するってニーズは、 もうないんじゃないかなと思います。 「なんだよーこいつ利いた風なこといってるけど全然英語聞き取れてないじゃん」ってなるのがオチなので。
ので、各トークの内容の要約はなるべく避けて、 背景とか前提とか、 聞きながら私が思ったり感じたりしたことを書き出す……というのが、この記事の趣旨です。 いや、そういうの別によいから……と思う人は、そっ閉じしてくださいませ……。
ビデオや資料が公開されたら順次こちらでも共有していく予定。
この記事は全３回予定です。
- その１：LibreOfficeプロジェクトとコミュニティ
- その２：技術・実装
- その３：その他（移行など、openSUSE関係、全体の感想）
LibreOfficeプロジェクトとコミュニティ
Opening Session and Address by Lothar Becker / 2020 October 15 - 10:00
登壇者のLothar Becker氏はThe Document Foundation（以下TDF）のThe Board of Directors（取締役会、以下BoD）議長です。
内容はともかくとして（オープニングなので）、当初利用予定だった https://oslo.gonogo.live/ がトラブって、 スライドの投影はできないしなんだりかんだりで、 しょうがないのでスライドなしでLotharが挨拶して、その裏でTDFのインフラチームが、 TDFがホストしているJitsi meetでイベント行えるように急遽準備して、 なんとかイベント開催できるようになった……そのなんというか、 ドキドキ感と感謝の気持ち、 それが先だっちゃって、話の内容はあんまり覚えてないです……ごめんなさいLothar。
Keynote from Collabora's Michael Meeks / 2020 October 15 - 10:30
LibOの開発・サポート企業の最大手、Collabora ProductivityのMichael Meeks氏によるキーノート。
そもそもCollaboraという会社がありまして、
LinuxカーネルとかGstreamerとかChromiumとかの開発・コンサルティングをやってる会社だそうです。詳しくないけど。
で、Collabora Productivityはその子会社で、LibreOfficeの商用版・長期サポート版Collabora Officeの開発・サポートなどなどをやっている会社です。 Meeks氏はそこの代表……だったはず。
ですから正しくはCollabora Productivity を付けるべきなんですけど、LibOの文脈だとみんな（本人たちも）断りなくCollaboraって言います。 私がこのブログとかSNSとかでCollaboraって書いたらProductivityを補って読んでください。
トークの内容は割愛するのですが、まあCollaboraはLibOの開発において最大のコミット数を誇る組織なので、 このキーノートで１年のLibO開発の大まかなトレンドがわかるところは、まあありがたいですよね。
大きなトピックとしては、LibreOfficeをブラウザー経由で動かすためのLibreOffice Onlineが、 TDFの配下からCollaboraアカウントのGithubに移ったことですね。
この理由についても説明があったんですけど、まあそれは込み入っているので彼らが公開しているFAQ見ていただくのがいいかなというのと、 私の感想は関連する別のトークのほうで書きます。
On sessions, statutes and software / by Florian Effenberger / 2020 October 17 - 11:00
TDFのExcective ProducerであるFlorian Effenberger氏によるTDFという組織についての講演。
TDFって実は約款に「LibreOffice」って文字は入ってないんだよーとか、「everyone contributes what they're best at（みんなが得意なことで貢献する）」って言葉とか、 一生懸命やってたら、それは普通の人生と一緒で緊張感がある対立することもあるよね、だけどそれを一緒に解決するの大事だよねみたいな話が印象的。
特に最後のは、今のLibOコミュニティはけっこうなんというか、 それこそ「緊張感がある対立」のさなかにあって、 それに対する感想としてはTwitterに書いたことでほぼ尽きていて、
（TDFの理想はすごい共感するし、それが、大してできもしない英語でカンファレンスに参加したりしてる理由だったりするのだけど、正直、理想を実現するためにがんばるとか誰かと利害を調整するとかが（それが非常に大事なことはわかってるんだけど）今のぼくにはつらすぎるんだよなあ……
— Naruhiko Ogasawara (@naru0ga) 2020年10月17日
（TDFの理想はすごい共感するし、それが、大してできもしない英語でカンファレンスに参加したりしてる理由だったりするのだけど、正直、理想を実現するためにがんばるとか誰かと利害を調整するとかが（それが非常に大事なことはわかってるんだけど）今のぼくにはつらすぎるんだよなあ……
ってことなんですよね……。
COVID-19のせいなのかなんなのか、 私はもう議論を積み重ねるとか、利害対立を丁寧に解決するとか、 そういうことをできる精神状態じゃなくて、 そういうの見てるだけでもけっこうつらくて、ねー。
あとですね、プレゼンのなかで、2016年のチェコのBrnoのLibreOffice Conferenceの集合写真が紹介されて、 Jitsi meetのチャット欄で「この写真に写ってる人挙手！」って呼びかけに、ぱぱぱぱぱって手の絵文字が並んで。
このLibOConって、私現地まで行ったけどカンファレンスに参加できなかった年なんですよ。入院してね。 Florianと、TDFの秘書役のSophieと、あと日本人参加者で作ってくれたFacebookメッセージチャットでFlorianが、
「ゆっくり休養してね、我々はみんな、君もこのカンファレンスの参加者だと思ってるから！」
って言ってくれて。まあ既出なんだけど、私は思わず病院のベッドで布団かぶってしくしく泣いたりしたわけですよ。おっさんがキモいけど。 この、チャット欄を流れる手の絵文字を眺めながら、それを思い出してました。
LibOってそういう、Florianに限らずほんとに温かい人がたくさんいるコミュニティで、 良くも悪くも家族的だったりするんですよね。 そういう人たちとチャット欄で話してると、 いや確かに今は解決すべき対立関係があってそれを見ているとしんどいけど、 だからといってまったく縁を切るんじゃなくて、 「コミュニティの一員」としてそういうのに立ち向かうのは無理としても、 付かず離れずの関係はもっておきたいな……と思いました。 そういう困難に立ち向かってる人への尊敬の念は忘れないようにしつつね。
って、これトークの感想じゃないな……。
The history & pre-history of LibreOffice / by Michael Meeks / 2020 October 16 - 13:30
OOo時代からLibOの歴史を振り返る的な……。
他のトークと重複するところもあるので箇条書きで。
- 端的に感想を言えば超おもしろかった*1。
- 「非協力的な非貢献者……アジア地区で典型的……」つまりコードをforkして開発するけどその変更をcontribute backしないことについて触れてる。これについてはまた別のトークにて。
- 2011年7月のパリの第一回LibOConで、すでにブラウザバージョンの試作なんてのが発表されてたとは知らなかった。
- 2012 - Becomes clear: Linux Desktop economics suck ;)
- こういうディスカッションに入っていくには自分の英語力では全然足りないですね。
Ecosystem, Branding & Investment / by Michael Meeks / 2020 October 17 - 15:15
すぐ上で紹介したトークの続き的なところもあり。
ここでいう「エコシステム」というのは、平たく言えばLibOでビジネスしてる組織、 プロフェッショナル開発者を雇用して、コードやその他で大きく貢献して、 さらにはTDFのAdvisory Board*2 だったりする組織です。
いくら高邁な思想があっても、みんな霞を食っては生きていけない。 なのでフルタイムにせよパートタイムにせよ、開発者を雇用する組織があることは、 とっても大事なのです。「エコシステム = 生態系」って言葉もわかる。
でま、Collaboraはコミット数ベースで4割ぐらいをたたき出している、 LibOのエコシステムのある意味代表なわけですね。 その彼らと、少なくともコミュニティの一部が、若干利害が対立しているところがあって。 LibreOffice 7.0のリリース前のテスト版に「Personal Edition」ってのが入っててちょっと揉めたというか話題になったというか、 そういうことがありましたが、これはこういうエコシステムとコミュニティの対立を解決しようとするさまざまな試みの一部が、 漏れ出してしまったところがある……というのが私の理解です。 まあ、そういう難しい話題をいろいろ考えましょう。というトークです。
もちろん、CollaboraのGeneral Managerという立ち位置のMeeks氏の視点からなので、 そこはもちろんバイアスがある話なわけですが。
繰り返すように私はこういう利害対立について意見をするには少々理解がおぼついていないところがあります。 なので一点だけ。
オリジナルのソースをForkして「ローカル版」として商用版をリリースして、 その修正をcontribute backしない、 そういう例はアジアではしばしば見受けられる。
といって、中国のRed Flag LinuxのOffice実装や、台湾のLibreOfficeフォークのOxOfficeのことを名指しで批判しているように聞こえました。
正直私はこれらのオフィスについてそれほど知っているわけではない*3 のですが、アジア圏のLibO（あるいはOOo）のフォークが自分たちの変更をフォークもとに戻さないことについては、ちょっとだけ思うところがあります。
まず、我々東アジア圏の人間がLibOに手を入れようと思う多くの動機はCJK周りの不具合なんじゃないかと思います。 しかし、LibOの実装は、「自分がこれに手を入れたら壊れるのではないか」と不安になる程度は複雑に思えます*4。「日本語が正しく出るように直したらアラビア語が壊れた！」とならない自信を持つのは非常に難しい。
LibOの開発はやってないけど一応プログラマーである私から見ると、「今ある問題をとりあえず解決する」コーディングと、「あるべきようにきれいに問題を解決する」コーディングにはだいぶ距離があって、ローカルな市場だけを考えたら「とりあえず対象の言語だけが直るような修正」は前者で、それだけをやってればビジネスになるとしたとき、後者までやる合理的な理由はあるのか。
もちろん、理屈の上では、upstreamから改善点をインポートし続けるつらさを考えると、upstream firstで進めていくほうが合理的……というのは、あります。
けど、ここでもう一つあって、ちょうど、oSLOが終わったあたりでTwitterを見たら目についた書き込み。
#cfjsummit Day1終了後の深夜に話されてたOSSのフリーライド問題、日本ではやはり言語の壁が要因の一つだと思う。「コーディングに自信はあっても英語には自信がない」という人は多い。英語圏OSSへのコミットをサポートする取り組みは必要。来年のアンカンファレンスのテーマかな
— MaySoMusician (@MaySoMusician) 2020年10月17日
cfjsummit Day1終了後の深夜に話されてたOSSのフリーライド問題、日本ではやはり言語の壁が要因の一つだと思う。「コーディングに自信はあっても英語には自信がない」という人は多い。英語圏OSSへのコミットをサポートする取り組みは必要。来年のアンカンファレンスのテーマかな
この理由ってめちゃめちゃある気がするんですよね……。
gitのコミットコメントを英語で書くのがまずたるい。
Gerrit上でレビューコメントがついたときに英語で議論するのがしんどい。
そんなしんどい思いをするぐらいならupstreamの変更を取り込むときにしんどい思いをするほうがまし。
少なくとも私は、そう思わない自信がないです。
なので、「アジア圏では各国語版みたいなの作ってupstreamに貢献を戻さないことがよくある」と言われてしまうと、 だってそれはあなたたちが貢献を戻すよりもずっとコストが高いんだもの……と、なってしまうんじゃないかな……。 そこのコストを下げる取り組みをしないで、upstreamに貢献を返さないなんて！と正論を言われても、 対立は解消しないんじゃないかな。 そんなことを思いながら聞いてました。
……なんてことを日本語で書いても、意味ないんですけどね。
そもそも、「コストを下げる取り組み」にいいアイディアはないですし。だめじゃん。
……ぜんぜん、カンファレンス参加メモじゃないですね。次行きます。
地域コミュニティ
日本語チームからもこのネタの発表あったけど、前述のとおりドロップアウト組としてはちょっと無理で聞けてませんでした。 でもイベント参加者向けTelegramとか、次のコマを聞きに行ったときに垣間見えたJitsi meetのチャットログとかを見ると、 どちらもとても好評だったようで喜ばしく思います。
それ以外の地域コミュニティ事例、韓国とインドネシア。
Building LibreOffice Korean Community and CJK's common & different issues / by DaeHyun Sung / 2020 October 16 - 10:30
感想としては、「デヒョンさん話題盛り込みすぎだよ～」でした :)
私は彼と直接話も何度かしてるし、なんといってもCJK文化圏ではあるのでそｒなりに話題についていけるんですけど、 あれ文脈が全然ない人にはちょっと難しかったんじゃないかな……Jitsi meetのチャットでも「スライドめくるのはやいよー」って意見が出てたし。 ちょっともったいない気持ちがしました。
トピックとしては：
という感じでしたが、三番目の話とかもっと掘り下げて聞きたいな、とは思いました。 DaeHyunさんにとっては初のLibOCon登壇なので、色々話したかったのはすごいわかるんですけどね。
でもRed Star OS付属のオフィスソフトのスクショの話とか、北朝鮮のクライシスマッピングについてのAkademy 2018のキーノートについてとか、いろいろ面白いトピックが詰め込まれた内容でした。Akademy 2018のキーノートは前にもお話聞いたんですけど、ちゃんとチェックしてなかったので改めてビデオ見てみようって思いましたです。
DaeHyunさん、おつかれさまでした！
Building Upstream Contribution in Local FOSS Community / by Kukuh Syafaat / 2020 October 16 - 11:15
インドネシアは若いOSS活動家がたくさんいる非常にアクティブなところです。 2019年に行ったLibreOffice Asia Conferenceにも、2017年にお手伝いしたopenSUSE.Asia Summitにも、大勢来てくれました。
でも、正直な話、ちょっと前までは「なんかすごい盛り上がってるみたいだけど、じゃあ、中で何やってるの？」という気持ちが、私の中になかったとは言わないです*6。
それが、特にデザイン回りでの貢献がすごい。例えばLibO 7.0の新機能紹介のビデオはインドネシアチーム編集です。
今回のoSLOのロゴは、このトークの登壇者Kukuhによるものですし：
OpenOffice.org / LibreOffice 10/20 ステッカーのデザインもやっぱりインドネシアのRania Amina氏によるものです。
こうやって、「デザインはインドネシア」みたいな色があるっていいですよね。LibreOffice IDのFacebookグループ3900人も参加者いるってのもすごいです。
……って、これもぜんぜんトークの感想じゃないな……。
ま、そんなわけで、クッソ長くなってしまいましたがいったん終わり。明日以降、その２を書いていこうと思います。
*1:去年のLibOConでItaloが「10/20の記念としてOOo/LibOの歴史書を書こうと思う」みたいなこと言ってたの思い出した。あれ実現しないかなー。
*2:お金を出す代わりに「アドバイス」をする権利がある組織、 平たく言えばスポンサー。
*3:公平を期するためにいっておくと、今TDFのBoDの副議長でもある台湾のFranklin Weng氏とは仲良くさせてもらってますが、FranklinはもちろんOxOfficeな人たちとつながっています。そしてその縁で私もOxOfficeの中の人と一度ご飯を食べたことがあり、Facebookのお友達だったりもします。
*4:私はろくすっぽ開発やってないですが、我らがCJKヒーロー台湾のMark Hung氏も、LibreOffice Asia Conference 2019の基調講演で似たようなことを言ってたと思います。
*5:Contribution + Malathonの造語らしい。日本で言えば未踏みたいなものかしら？
*6:おんなじことはLibOでも「日本のコミュニティイベントたくさんやってるしとっても活発だけど、なにやってるのかさっぱりわかんないよ」って言われてましたけどね。
【個人的メモ】openSUSE + LibreOffice Virtual Conferenceで何を見るか（Day3: 10/17）
いよいよ来週10/15～17に迫ってきた：
について、LibreOfficeにもopenSUSEにも直接かかわりあいのない微妙な立場のわたくしがこの話気になるなとかこの話参加したいなということをダラダラとメモる記事、いよいよ最終日。
ではまいりましょう。例によって時間はJSTです。
19:00-19:30 [LibOCon] « LibreOffice Python scripting made simple w/ IDE_utils » - Dev/Doc tracks
16日に似たようなトークがあるけどあっちはBasicでこっちはPython。 LibO+Pythonはちゃんと組み立てれば結構日本でもウケるネタになる気がするんだけどな、と思いつつ思ってるだけ。なので聞いてみる。
裏番組でFirebirdの話をしたりするのでこれも面白そうではあるけど……。
次に野方さんによる日本におけるマーケティングのセッションがあって、これ自体はぜひカンファレンスで話したほうがよいと思ってたし登壇いただける野方さんには感謝しかないのですが、 前述の通り日本のコミュニティの話を聞くのは私のメンタルがつらすぎるので*1 パスして……。
20:00-20:30 [LibOCon] On sessions, statutes and software
非営利組織であるTDFの10年から学んだこと……みたいな。ガバナンスとか透明性とか。
いまこういう話題ちょっとニガテな感じなので、これもパスするかもだけど、Florianは超いい人だし聞くかもリストには積んでおきます。
21:00-21:30 [LibOCon] History of Online & Mobile
LOOLと、LOOLベースで開発中のCollabora Office for mobile（って名前だっけか）のデザイン上の決定とかなんとか。そんなに深入りした話にはならないとは思うけど。
しょうがないけどここから３コマぐらいは聞きたい話が全部かぶっていて残念。逆にいうと後からビデオ見る楽しみが多いということで結構です。
21:30-22:00 [LibOCon] LibreOffice Document Encryption API
このトピック自体もそうだけどUNO APIを叩いて外部からLibO操作するってことについてもう少し知っとくと本業でも役に立ちそうかなって。
22:00-22:30 [LibOCon] Online – Improving visual consistency
これもLOOLネタ。だけどちょっと毛色が違って、LOOLのDOM要素をどうやって掴みやすくするかとかそういう話っぽい。 元SeleniumによるWeb自動テスト屋さんだった人間としては気になる。
23:00-24:00 [LibOCon] LibreOffice Virtual Hackfest
通常のHackFestじゃなくて開発関係のQ&Aコーナーらしいんだけど、 ホストのIlmariが「質問全然こないよーこのままだとキャンセルになっちゃうよー」ってちょっと前にぼやいてた……。 なんか考えないとな。って、まだ間に合うのかなあ……。
ここも裏番組いろいろ面白そうなんだけどね……。
24:15-24:45 [LibOCon] Ecosystem, Branding & Investment
この議題もちょっと自分ダメかもしれないけど、大事なので聞けたら。
24:45-25:15 [LibOCon] Closing Session
例年だとここで来年のカンファレンスの開催地発表があるんだけど今年はどうなるんだろうね……。
25:15-26:15 [LibOCon] LibreOffice 10th Anniversary
お祝いはうれしいことだけど次の10年に向けて今LibOコミュニティは結構タフな議論をしていて、 それを見てるのが結構しんどい今の私にとっては、 この1時間でどんなことをするんだろう……というお気持ちでありまする。
ま、お祝いなのでもちろん参加しますけどね。
終わりに
書き出してみたらけっこう長時間なイベントなので、この通りに参加したらぶっ倒れてしまいそう……ｗ
ま、でも、面白そうなトークに丸付けできてよかったです。こういう機会でも作らないと真面目にプログラムチェックしないもんな。
繰り返しますけど個人的メモなのですが、面白いなと思ってもらったり、なんかの役に立ったり（ないか……）したら幸いです。では、楽しみましょう！
*1:ホント、ひ弱ですみません
【個人的メモ】openSUSE + LibreOffice Virtual Conferenceで何を見るか（Day2: 10/16）
いよいよ来週10/15～17に迫ってきた：
について、LibreOfficeにもopenSUSEにも直接かかわりあいのない微妙な立場のわたくしがこの話気になるなとかこの話参加したいなということをダラダラとメモる記事、その二日目。
この日と翌日は、土日休みのサラリーマン的には、仕事を気にせず夜更かしできるのでいいですね。
この日の最初、日本時間19時から日本のコミュニティにおけるCOVID-19な状況下におけるチャレンジについての発表があるけど、 まさにその状況下でドロップアウトした自分にはメンタル的につらいのでパス……すると思う。 でもきっと興味深い内容が話されると思うので、興味がある皆さんぜひ参加してほしいな。LibOじゃない人にも参考になるかも。
ではそのあとから。例によって時間はJSTです。
19:30-20:00 [LibOCon] Building LibreOffice Korean Community and CJK's common & different issue
韓国で頑張ってるDaeHyun Sungさんの発表。これも正直、個人的なかかわりが近すぎてしんどい気がするので聞くかどうか悩んでます。きっと面白い内容だとは思うんですけどね。
20:00-20:15 [LibOCon] Working with native/indigenous communities to build native language LibreOffice projects
たぶん去年のLibOConでやった「Making LibreOffice a lifesaver for dying languages in Asia」って発表のアップデートじゃないかと思う。 台湾先住民族の言葉を保護するためにLibOで対応させようって話。技術面だけじゃなくて政治的な問いかけとしても非常におもしろかったので続きであれば聞きたい。
20:15-20:30 [oSC][LibOCon] Building Upstream Contribution in Local FOSS Community
登壇者のKukuh Syafaat氏は知り合いなので……ってのと、少しばくっとした内容だけど、地域コミュニティが活発なインドネシアだからこそ、upstreamへの貢献どうするのって話は興味があります。
20:30-21:00 [LibOCon] OOXML / PDF Digital Signing in Draw and elsewhere
LibOにはデジタル署名の機能があることはもう皆さんご存じかと思いますけど、これをDrawからOOXML/PDFにエクスポートするときにもサポートしたよって話。 わからないなりに実装の話を聞くの好きなんです。
21:15-21:30 [oSC] IT Risk Management Based on ISO 31000 and OWASP Framework using OSINT (Case Study: Election Commission of X City)
セキュリティには明るくないのですがわたくしいちおうセキュリティベンダーの社員ですので……。
22:00-22:30 [LibOCon] « LibreOffice Basic/VBA hidden gems » - Dev/Doc Tracks
失礼な物言いながらすごくこのトピック興味があるってわけじゃないけど、 裏番組も特にないので、なんとなく聞こうかなって。聞けばきっと面白いと感じる部分はあるので。
いや、
こういう「重要で」「意味があり」「議論すべき価値がある」ディスカッションもありますけど、 わたくしこういう議論、もう見てるだけでしんどくて距離を置きたいのです……。よわい。
22:30-23;00 [LibOCon] The history & pre-history of LibreOffice
タイトルまんま。若干きな臭いにおいがしなくもない（？）けど、面白そうです。
23:30-24:30 [LibOCon] Google Summer of Code 2020 Panel
今年のGSoCの成果報告。今年もよい成果がいっぱい出たみたいなので。参考↓
Impressの物理エンジンアニメーションとか実用性はともかくとして面白いですよね。
でも途中で抜けちゃいます。というのは、これ↓があるから。
24:00-24:30 [LibOCon] Implementation Detail
sbergことStephan Bergmann氏のC++仕様ネタ、私好きなの……むしろファンと言ってもいい。
25:00-26:00 [LibOCon] How to debug Writer, forwards and backwards
これは参加しないわけにいかないでしょう……>< 裏番組も面白そうなんですけどね。Public Money, Public Codeの話とか。 でもこっちは動画で追いかけられるので。
26:00-26:15 [LibOCon] The ODF Toolkit
TDF純正ODF操作ライブラリODF Toolkitの現状。へーしゃももう開発止まってるライブラリからこっちに移行したい……。再実装するか（？
26:15-26:30 [LibOCon] Marketing and social media in LibreOffice
「マーケティング」は私のやりたいことであったことは過去においてもないけど*1、ま、冷やかしです。
27:00-27:30 [LibOCon] Improvements to PDF support in Collabora Online
LibOはDrawでPDFを読み込んで編集できる機能があるけどこれをOnlineに実装したよってことかな？ こんな機能あるの知らんかったので……。
しかしそろそろ起きてるのきついと思われる時間なので、あきらめて落ちる可能性もあります。
27:30-28:00 [LibOCon] The importance of ODF for Digital Sovereignty strategies
Digital Sovereigntyって「デジタル主権」とでも訳すのかな？ ここらへんがとっかかりでしょうか。
EUのホワイトペーパーらしきもの（PDF）651992_EN.pdf)も出てきたけど、さすがにこれを読むのは胃もたれしそう……。 ま、とにかく軽い理解ではベンダーロックインからの解放とかそういう文脈の言葉みたいですね。
時間も遅いけど、興味深くはあるから起きられたら聞いてみましょう。
28:00-28:30 [LibOCon] LibreOffice AppImages: Past, present and future
AppImage便利なんだよねーQAっぽいことをするには。これも起きられたらだな。
29:00-29:30 [oSC] Hat making
Fedoraってどうやって作られてるの？ みたいな話。さすがに時間遅すぎるけど興味はあります。
……まだプログラムは続くけど、私が聞くかも？って内容はここまで。もっと手前で脱落する気がするけど……。
では記事は三日目に続きます。
【個人的メモ】openSUSE + LibreOffice Virtual Conferenceで何を見るか（Day1: 10/15）
表題のイベントの開催が、10/15-17と、そろそろ迫ってきました。
毎年秋にヨーロッパ圏で開催されているLibreOffice Conference:
が2020年はopenSUSEの年次カンファレンスopenSUSE Conferenceと共同開催で、openSUSEの本部があるドイツのニュルンベルク……だったはずなのですが、残念ながらCOVID-19の影響でバーチャルカンファレンスになったよというわけです。
いろいろあってそれぞれのコミュニティには顔と名前が一致する人も一方的にしかわからないけど発言気にしてみてる人もまあまあいるし、 リモートなので参加しやすいので、仕事に穴が開かない程度にできれば多くのトラックみたいなと思ってるわけです。時差つらいけど。
それで、これ気になるな、面白そうだなってプログラムをメモっておこうと思いまして。 そんな個人的なメモであっても誰かの何かの参考になるならと思って、記事にすることにしました。
書いてみたら結構長くなっちゃったので日付ごとに三分割。
なお同イベントのプログラムはこのカレンダーを参照してくださいませ。
免責事項（？）
私の立ち位置はこんな感じです。「両プロジェクトにうっすら好意を持っている他人」だと思ってください。
- LibreOffice
- プロジェクト発足から少し経ってから翻訳を手伝ったりして、あんまりリードしてない翻訳チームのリードだったりもしました
- イベントを手伝ったりコミュニティを代表するような形で登壇するようなこともしてました
- が、今現在あまりにも何もしてない（できない）自分にいやになったのが主な理由でまるっと辞めました。積極的にかかわるのも苦痛になってしまったので今は外から見ることもあまりしてません
- まだThe Document Foundationのメンバーではありますが、次の更新は多分しないと思います
- 言ってしまえば、もともとプロダクトとしてのLibreOfficeに限らずオフィスソフト自体にそんなに愛はないです
- ただ、LibreOfficeが目指す世界は私の理想と近いところがありますし、LibreOfficeがある世界の方が私には望ましいです
- 職業的ソフト屋としてはLibO/ODFを部品的に使うほうにむしろ関心が高いです
- 開発に挑戦してみたい気持ちは継続して一応持ってます。今年は初めての「意味がある」コミットもしたしね
- LibreOffice Conferenceは2012年のベルリンに参加したのが初めで、5回（あと現地に行ったけど参加できなかったのが1回）ほど参加してます。うち登壇は4回だっけか……
- なので顔と名前が一致する人たちもそこそこいて、その人たちの活動を応援したいなあとは思ってます
- openSUSE
- 実はちゃんと使ったことは一度もないです、ごめんなさい
- OSSにかかわるようになった最初期のころ（2008年～2009年ぐらい？）、openSUSEの週刊ニュースレターの翻訳手伝ったりしてました。たぶんこれが私の印刷系以外の初めてのOSSコントリビュートかな
- 私自身はUbuntuユーザーだけど日本のopenSUSEユーザーな皆様も知り合いにはそこそこいますし、まあ仲良くしてもらっていると思っていいのかな
- openSUSE.Asia summitというイベントがあって、理由はよくわからないけどグローバルチームの立ち上げメンバーだったりしました。東京開催のときにはお手伝いしたりもしましたよ
- ついでにいうと私はUbuntuも単なるデスクトップOSとしてしかほぼ使ってないので、Linux自体まったく詳しくないです
そんな中途半端な立ち位置な私によるこの記事は個人的なメモであり、何か役に立つ情報を皆様に提供しようとするものではありません*1。
「コミュニティの中の人」によるおススメを知りたければ、ぜひこのイベントへの参加をご検討ください。きっと面白いと思います！
では次から私が見るであろう、見たいなあ、ってプログラムをダラダラと書いていきます。LibreOfficeなトラックには [LibOCon] 、openSUSE Conferenceなトラックには [oSC] というタグをつけます。時間は日本時間。
19:00-19:15 [LibOCon] Opening Session
まあオープニングですので。参加しやすい時間なのでお付き合いしましょう。15分ですし。
19:30-20:00 [LibOCon] Keynote from Collabora's Michael Meeks
LibreOfficeのサポートベンダーとして最大勢力であるCollabora Productivity（以下単にCollabora）を率いるMicheal Meeksによるキーノート。 スポンサーキーノートとはいえLibOの多くのコミットはCollaboraによるものですし彼の話は純粋に面白いので*2 これは普通に聞きたいです。
20:00-20:30 [LibOCon] State of CJK issues of LibreOffice, 2020 edition
榎さんの、毎度おなじみ、LibreOfficeのCJK問題についていろいろ説明するよって内容。これもLibOConの定番になりましたねえ。継続は力なり。すばらしい。
CJKの問題に興味がある人はQ&Aタイムで重ねて補足したりなんだりするチャンスですが、私はそういうのもうしんどいので隅っこでおとなしく聞いてますｗ
20:30-21:00 [oSC]Podman on Kubernetes Cluster Production Grade
裏番組の「高等教育用のLinuxディストロってどうなん需要あるん？」みたいな話もプチ気になりつつもお仕事的はこっち。
21:30-22:00 [LibOCon] Introduction of Libre Office and ODF in Aizuwakamatsu City
会津若松市の目黒さんによる会津若松市のOOo/LibO導入についてのプレゼン。 この話を世界でちゃんと発信できるというのはむちゃくちゃ有意義だと思うのです。 日本の事例は過去に私とか榎さんが小出しに紹介したことはあっても、 1セッション割かれるのはほぼ初めてなので*3。
内容は、正直な話、私にとって新しい話が出てくるとはそんなに思ってないんですが、質疑応答でみんながどんなことを聞いてくるのか気になるので、これは聞かなきゃですかね。 当然日本からの参加者いっぱいいるだろうしSNSとかで共有される気もしますけど、そこはほら、ライブ感ってのは大事なので。 裏番組のAsh氏のLOOLのサイドバーの実装の話も面白そうなんだけどね……。
22:00-22:30 [oSC] Monitoring and managing Containers using Open Source tools
これもお仕事的に。正直明るくない分野なのでぼーっと聞くだけになりそうではあるけど。って、ビデオついてるからこれ見ればいいのか……？ｗ
裏番組の「Open Source Project Governance and Management Practices」ってのも少し気になったけど登壇者情報がカラだとか内容が一般的過ぎて具体性が全然ないとか微妙なので、まあこっちかなと。
22:30-22:45 [LibOCon] Bringing the Notebookbar to Online
単純にLOOLのUI関係の実装は聞いてて知的好奇心をくすぐられるので……。
23:00-23:30 [LibOCon] Implementing Vulkan-capable drawing using the Skia library
LibOのプラットフォーム共通ウィジェット描画ライブラリVCL（Visual Class Library）を新しいプラットフォームSkia/Vulkanで実装したよという話。 これはLibOの実装的にはかなり大きなトピックなんだけど私あんまり把握できてないので*4、まあ、聞いておきますかと。
これがState of the Project の裏番かーそうですかー。まあ、こっちは後でビデオで追いかければいいか……。
23:30-24:00 [oSC] Keynote from SUSE's Markus Noga
SUSEによるスポンサーKeynote。 すごい聞きたいわけじゃないけど（失礼）、スポンサー様のセッションのPVは回した方がいいのかなって。ただ、休憩タイムに充てちゃう可能性は多分にあります。
24:00-24:30 [LibOCon] ODF state of the union - ODF 1.3 ante portas 15:00
ODF標準化についてのあれこれ（だと思われる）。 ODF 1.3は2020年末にOASISの委員会標準になって、今年ISO化を目指すって話だったと思うけどCOVID-19の影響はあるんでしょうか（知らない）。
24:30-25:00 [LibOCon] Making Online trivial to setup 15:50 UTC
小規模環境におけるLOOLっつかCollabora Onlineのインストールを超簡単にしたよ、その技術解説するよって内容ですね。そろそろおねむの時間だけど、これは聞きたいなあ……がんばろう。
お仕事に影響がない範囲だとこの程度かなあ。この日はそれ以外にここら辺が気になるけど、さすがに参加できないです。
- Evaluation of new tooling and web applications for LibreOffice contributors 17:00 UTC = 26:00 JST
- LibOの貢献者向けWebインフラについてのディスカッション。 コミュニティメンバーとして活動してた、例えば去年なら仕事休んででも参加してたと思うけど、 今は自分のわがままで（特にローカルの）コミュニティと距離を置いているので、参加しても意味がある意見を言えないというのはあります。
- LibreOffice oss-fuzz, crashtesting, coverity 17:30 UTC = 26:30 JST
- この話去年のカンファレンスでもあって、本業的にも面白かったのでむっちゃ聞きたい！ けど、次の日使い物にならなくなりそうだしなあ……ビデオで追いかけるかなあ……
- The ODF TC GitHub 18:00 UTC = 27:00 JST
- ODFの標準化関係のツールについて。Svanteの話面白いですしね。しかしさすがに……むむむ
……初日だけなのにクソ長いエントリになっちゃったのでいったん切って次行きます。
短期集中連載？ LibreOfficeをWindowsで開発してみよう：補足その②パッチの提出 and more...
GWの間にLibO開発できる環境をWindowsで作ろうの連載をやりました。
そして、修正パッチ作って投げたのでその気づいた点を書いてたら長くなったので分割したのが：
この記事はその続きで、
- ユニットテストをどう書いてどう実行するか
- パッチをどうやって送るか
- ヘルプの更新の仕方
のうち 2. と、3. をほんのちょっと……です。
2. パッチをどうやって送るか
こいつについては例によって公式にとても丁寧に説明があるのでそれに従えばいいです。
LibreOfficeのソースコードは、コードレビューシステム Gerrit で管理されてます。
https://gerrit.libreoffice.org/:embed:site
Gerritの設定についてのドキュメントはこちら。
まずはGerritにアカウント作るところからですが、私大昔にアカウントだけは作ってあったのでそこは省略。アカウント設定で「ユーザー名」を確認、それとSSH鍵も登録しておきます。
そしたらあとは簡単で、 ./logerrit setup すればよいはず……だったんですが、なんか私はうまくいかなくて (~/.ssh/confg が正しく更新されなくて）、手で config 書いたらテスト通りました。
そしたら次はパッチの提出です。ドキュメントはこちら。
やることは、masterから分岐して変更コミットを持つブランチにて、
./logerrit submit master
ってするだけです。 前回の記事にもちろっと書きましたがCIこけたりして再度コミットやり直したりしたのですが、 そのときはamendまたはrebaseでコミット改変すればOK。コミットコメント見ると：
Change-Id: ???????056191
みたいなのがついてますが、Gerrit上の変更はこいつが維持されると反映されるみたい。
で、提出してJenkins通ったのち。 どうも自信がなかったのですが、たとえばコード修正して、その修正に対応したテストケース書いて、みたいな変更のとき、 コミットは分割するものかそれとも一つにまとめるものか悩ましかったのです。 ただ、ほかの人のコミットを見るとあんまり分割されてなさそうなので、えいっとrebaseで一つにしちゃいました。 このときは最後のコミットの Change-Id を残せばいいみたいですね。
こうやって再提出するときも：
./logerrit submit master
するだけです。簡単ですね。
それから、「こういう書き方でいいのかちょっと見てくれる？」みたいなときに、
Work In Progressなままあげるって機能もあって、その場合は ./logerrit submit-wip master とすればいいですよと。
WIPで上げた変更をちゃんとした変更に昇格する方法もあるのかもしれないですが、 私は、この変更とは別に別にsubmitしちゃって、WIPのほうはabondon（取り下げ）しちゃったので、 よくわからないんですよね。 その点は各自適当にアレしてくださいませ。
3. ヘルプの更新の仕方
さてさて。
今はレビュー待ちでドキドキしてるところですが、それで終わりではありません。
今回は、仕様変更したのですが、この仕様はヘルプにも記述がありまして：
こいつも直さないといけないじゃないですか。
で、ヘルプ入りでビルドしないとだめなのかなー、と、
./autogen.sh の実行時オプションに --with-help を指定したんですけど、
今の時点では、これはいらんかったのではと思ってます。
というのは、LibOのソースツリーにおいてヘルプは helpcontent2 という submodule になってまして、
submoduleなので、このツリー上で変更したところでコミットするすべがないし、
Gerritにおけるパッチ管理も別。
いや、
ここにあるやりかたをすればいけるのかもしれないですが、
なにせ --with-help するとビルド時間がめちゃくちゃ伸びるのです。
だったら、別のツリーとしてcloneして、そっちで作業した方がいいんじゃないか……？ というのが、 今のところ思ってるところです。
最後に小ネタ： ./autogen.input 書こう
短期集中連載の、たとえば第1回とか第3回とかで、./autogen.sh に引数こんなふうに渡して実行してました。
./autogen.sh \ --with-lang=ALL \ --enable-64-bit \ --with-jdk-home=/cygdrive/c/Program\ Files/AdoptOpenJDK/jdk-8.0.252.09-hotspot/ \ --enable-debug
それより、同じディレクトリに autogen.input ってテキストファイルを転がしておく方がベターです。こんな感じ。
--with-lang=ja en-US ko zh-CN zh-TW --enable-64-bit --with-jdk-home=/cygdrive/c/Program\ Files/AdoptOpenJDK/jdk-8.0.252.09-hotspot/ --enable-debug
このファイルがあれば、 ./autogen.sh と引数なしで実行したとき、ファイルに記載したパラメータありで実行されます。
autogen.input の書き方はみたまんまなのですが一点だけ注意、--with-lang みたいに複数のパラメータを取るとき、
コマンドラインで渡すときは "" でクォートしますが、
autogen.input の場合はクォートするとエラーになります。
直前に実行したautogenの引数は autogen.lastrun ってファイルに保存されてるので、
こいつをもとに作るのがいいかもですね。
そんなわけで開発チャレンジはまだ始まったばかりですが、 この記事が、自分も開発やってみよう！ ビルドするだけじゃなくてバグ直したり開発したりしてみよう！ と思う人の参考になればいいなと思います。
LibreOffice Asia Conference 2019: LibreOffice CJK Bugs, Fixes, and Stories
（先日も紹介しましたけど）去年のLibreOffice Asia Conference 2019でMarkが言ってたように、 CJKの問題は非CJKな民が正しい動作を理解し修正することがとても難しいので、 我々自身で直せるものは直していきたいですよね。
求む！ 同志！
短期集中連載？ LibreOfficeをWindowsで開発してみよう：補足その①ユニットテストについて
GWの間にLibO開発できる環境をWindowsで作ろうの連載をやりましたが、あれからようやっと修正パッチ投げるところまでやりましたので、その中で気づいたことなど。
なお再度お断りですが、この一連の記事はLibreOfficeの開発について解説しようというものではないです。
というのは、解説記事をかけるほど自分詳しくないってことと、 LibreOfficeのように開発が活発なプロジェクトにおいて、 開発情報は将来において変わりうるので解説の寿命がそんなに長くないってことです*1。
あくまでも、Wikiにある公式情報：
を参照しつつ、私の記事は、 あーなるほどこんなところで引っかかったりするのかーみたいな一種のドキュメンタリーとして楽しんでいただけたら。
あともう一つ、第5回で、 問題のどこを直せばいいかというのはわかったつもりだけど、 どう直せばいいのか（仕様変更すべきなのか）がわかってないみたいに書きました。 それについては、メーリングリストに質問投げまして、 仕様変更になるかもだけど直した方がよかろうということに賛同いただきまして決着。 よかったよかった。
さてさて。前置き長くてすみません。本題。
実際に開発を進めていくにあたって、以下３点少し悩んだので。
- ユニットテストをどう書いてどう実行するか
- パッチをどうやって送るか
- ヘルプの更新の仕方
と、書いてたらむちゃくちゃ長くなったので、この記事はまずは①だけについて。②③は別記事にします。
1. ユニットテストをどう書いてどう実行するか
LibreOfficeのような、日々膨大な変更があって*2 リリース頻度も高いソフトウェアには、自動テストが欠かせません。
ロジックを何らか変えたら、 当然、テストを実行してリグレッション*3がないかどうかを確認し、 場合によっては、新たに実装したロジックが適切に動作するかどうかのテストを書かなくてはいけません。
LibreOfficeには自動テストのしくみがいくつかありますが、基本となるのはC++なロジックをC++なテストコードで確認するユニットテスト。 例によって公式Wikiに記載があります。
さて。「どう書いて」については、この記事ではお伝えできる情報あんまり情報がないです……。 今回のように既存のロジックを変えましたよという場合、そのロジックに関するテストを探して、 必要ならそいつに書き足す……ってな感じでしょうね。
で、前回同様「DBNum」でプロジェクト丸ごと検索かけて、今回は関係しそうなテストは二つ。
一つは sc/qa/unit/subsequent_export-test.cxx の以下の部分：
void ScExportTest::testNatNumInNumberFormatXLSX()
{
ScDocShellRef xDocSh = loadDoc("tdf79398_NatNum5.", FORMAT_ODS);
CPPUNIT_ASSERT( xDocSh.is() );
xDocSh = saveAndReload( &(*xDocSh), FORMAT_XLSX); // Convert [NatNum5] to [DBNum2] in Chinese
CPPUNIT_ASSERT( xDocSh.is() );
xmlDocUniquePtr pDoc = XPathHelper::parseExport2(*this, *xDocSh, m_xSFactory, "xl/styles.xml", FORMAT_XLSX);
CPPUNIT_ASSERT(pDoc);
assertXPath(pDoc, "/x:styleSheet/x:numFmts/x:numFmt[3]", "formatCode", "[DBNum2][$-804]General;[RED][DBNum2][$-804]General");
xDocSh->DoClose();
}
こいつは：
- 名前の通りエクスポートのときに NatNum -> DBNum の変換がちゃんとおこわなれるかのテストで
- あらかじめ用意したODSファイルをXLSX形式で保存しなおして
- 出てる内容のXPathで正しさを確認する
ってものなのですけど…… うーん、データファイル作るの少し面倒だし、 XPathの書き方もよくわかってないので*4 こいつはいったん置きます。
もう一つは、 svl/qa/unit/svl.cxx の以下のコード。
void Test::testUserDefinedNumberFormats()
{
...
{ // tdf#79399 tdf#101462 Native Number Formats
sCode = "[NatNum5][$-0404]General\\ ";
// Chinese upper case number characters for 120
sExpected = u"\u58F9\u4F70\u8CB3\u62FE ";
checkPreviewString(aFormatter, sCode, 120, eLang, sExpected);
sCode = "[DBNum2][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 120, eLang, sExpected);
...
こいつはセルの書式画面にて書式コードを手で入力するときの「プレビュー」をもとに、 書式が期待通りに処理されるかということを確認。お、これはわかりやすいですね。
もうちょっと読んでみますと、書式指定文字列らしい [NatNum5][$-0404]General\\、
この [$-0404] ってなんじゃろ……と思って調べたら、
ヘルプ によると、
include/lang.h にある：
#define LANGUAGE_CHINESE_TRADITIONAL LanguageType(0x0404) ... #define LANGUAGE_JAPANESE LanguageType(0x0411) ... #define LANGUAGE_KOREAN LanguageType(0x0412)
みたいですね。 今回の場合、 セル内の言語によって結果が変わることをテストしないといけないのでこれは大変に都合がよろしい。
で、 sExpected = u"\u58F9\u4F70\u8CB3\u62FE "; ですが、
これは適当なツール*5 UTF-16 デコードすると 壹佰貳拾 となって、
あーなるほど、checkPreviewString() の第3引数に渡してるやつの NatNum5 = DBNum2 の期待値なのですね。
ということでこのロジックはままコピれるみたいなので、 別個こんな感じでまとめました。ちょっと長いけど。
{ // tdf#130193 tdf#130140 Native Number Formats mapping for Chinese (Traditonal), Japanese, Korean
// -- Traditional Chinese: DBNum1 -> NatNum4, DBNum2 -> NatNum5, DBnum3 -> NatNum6
// DBNum1 -> NatNum4: Chinese lower case text for 123456789
// 一億二千三百四十五萬六千七百八十九
sExpected = u"\u4e00\u5104\u4e8c\u5343\u4e09\u767e\u56db\u5341\u4e94\u842c\u516d\u5343"
u"\u4e03\u767e\u516b\u5341\u4e5d ";
sCode = "[NatNum4][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum1][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum2 -> NatNum5: Chinese upper case text
// 壹億貳仟參佰肆拾伍萬陸仟柒佰捌拾玖
sExpected = u"\u58f9\u5104\u8cb3\u4edf\u53c3\u4f70\u8086\u62fe\u4f0d\u842c\u9678\u4edf"
u"\u67d2\u4f70\u634c\u62fe\u7396 ";
sCode = "[NatNum5][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum2][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum3 -> NatNum6: fullwidth text
// １億２千３百４十５万６千７百８十９
sExpected = u"\uff11\u5104\uff12\u5343\uff13\u767e\uff14\u5341\uff15\u842c\uff16\u5343"
u"\uff17\u767e\uff18\u5341\uff19 ";
sCode = "[NatNum6][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum3][$-0404]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// -- Japanese: DBNum1 -> NatNum4, DBNum2 -> NatNum5, DBnum3 -> NatNum3
// DBNum1 -> NatNum4: Japanese modern long Kanji text for 123456789
// 一億二千三百四十五万六千七百八十九
sExpected = u"\u4e00\u5104\u4e8c\u5343\u4e09\u767e\u56db\u5341\u4e94\u4e07\u516d\u5343"
u"\u4e03\u767e\u516b\u5341\u4e5d ";
sCode = "[NatNum4][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum1][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum2 -> NatNum5: traditional long Kanji text
// 壱億弐阡参百四拾伍萬六阡七百八拾九
sExpected = u"\u58f1\u5104\u5f10\u9621\u53c2\u767e\u56db\u62fe\u4f0d\u842c\u516d\u9621"
u"\u4e03\u767e\u516b\u62fe\u4e5d ";
sCode = "[NatNum5][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum2][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum3 -> NatNum3: fullwidth Arabic digits
// １２３４５６７８９
sExpected = u"\uff11\uff12\uff13\uff14\uff15\uff16\uff17\uff18\uff19 ";
sCode = "[NatNum3][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum3][$-0411]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// -- Korean: DBNum1 -> NatNum1, DBNum2 -> NatNum2, DBNum3 -> NatNum4, DBNum4 -> NatNum9
// DBNum1 -> NatNum1: Korean lower case characters
// 一二三四五六七八九
sExpected = u"\u4e00\u4e8c\u4e09\u56db\u4e94\u516d\u4e03\u516b\u4e5d ";
sCode = "[NatNum1][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum1][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum2 -> NatNum2: Korean upper case characters
// 壹貳參四伍六七八九
sExpected = u"\u58f9\u8cb3\u53c3\u56db\u4f0d\u516d\u4e03\u516b\u4e5d ";
sCode = "[NatNum2][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum2][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum3 -> NatNum3: fullwidth Arabic digits
// １２３４５６７８９
sExpected = u"\uff11\uff12\uff13\uff14\uff15\uff16\uff17\uff18\uff19 ";
sCode = "[NatNum3][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum3][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
// DBNum4 -> NatNum9: Hangul characters
// 일이삼사오육칠팔구
sExpected = u"\uc77c\uc774\uc0bc\uc0ac\uc624\uc721\uce60\ud314\uad6c ";
sCode = "[NatNum9][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
sCode = "[DBNum4][$-0412]General\\ ";
checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
}
さて、実行について。
さきのページにもありました通り、全部のテストを実行するには、
make check
するだけ。このときウィルスチェックがONだと失敗することがあるのでOFFっとくのがいいみたいです*6。
ただ、LibOのユニットテストはとても膨大なので、毎度毎度全部のテストを流すのはホネが折れます。 なので狙ったテストだけ流す方法もあります。
make CppunitTest_svl_qa_cppunit CPPUNIT_TEST_NAME="testUserDefinedNumberFormats"
たとえばこんな感じ。
今回書いたテストは svl/qa/unit/svl.cxx 以下にあるので、makeのターゲットは "svl_qa" となるというわけですね。
……いや、正直にいうと、たぶん ls svl/CppunitTest*.mk してそれっぽいものを探しただけな気がします。
なお、事前にモジュールがあるフォルダーに cd しておくと、ちょっとだけテストの起動が早くなりますね。
で、失敗したとき。このときもとてもよくできてまして、失敗するとこんな感じのメッセージが出ます。
C:/cygwin/home/naruhiko/lode/dev/core/svl/qa/unit/svl.cxx:437:`anonymous namespace'::Test::testUserDefinedNumberFormats equality assertion failed - Expected: 一億二千三百四十五萬六千七百八十九 - Actual : 一千二百三十四萬五千六百七十八 `anonymous namespace'::Test::testUserDefinedNumberFormats finished in: 736ms C:/cygwin/home/naruhiko/lode/dev/core/svl/qa/unit/svl.cxx(437) : error : Assertion Test name: `anonymous namespace'::Test::testUserDefinedNumberFormats equality assertion failed - Expected: 一億二千三百四十五萬六千七百八十九 - Actual : 一千二百三十四萬五千六百七十八 Failures !!! Run: 1 Failure total: 1 Failures: 1 Errors: 0 warn:unotools.config:1836:23384:unotools/source/config/configmgr.cxx:140: ConfigManager not empty Error: a unit test failed, please do one of: make CppunitTest_svl_qa_cppunit CPPUNITTRACE=TRUE # which is a shortcut for the following line make CppunitTest_svl_qa_cppunit CPPUNITTRACE="'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/devenv.exe' /debugexe" # for interactive debugging in Visual Studio make CppunitTest_svl_qa_cppunit CPPUNITTRACE="drmemory -free_max_frames 20" # for memory checking (install Dr.Memory first, and put it to your PATH) You can limit the execution to just one particular test by: make CppunitTest_svl_qa_cppunit CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
そう、ここに書いてある通り、
make CppunitTest_svl_qa_cppunit CPPUNITTRACE=TRUE
ってやると、Visual Studioが立ち上がって、この中でユニットテスト（と、もちろん、その中で呼び出されるLibOのコード）をデバッグできるんですね。 当然 ‘CPPUNIT_TEST_NAME` との併用も可能です。
これで、新規に作ったテストがちゃんと通るようになったら、あらためてユニットテストもgitにコミットして。
コミットしたコードで正しくテストが全部通るかどうか、 make check をもう一度やっておきましょう。
わたくしはこの工程をさぼったため、先に示した svl/qa/unit/svl.cxx のテストの実行がCIでfailしてあわわわわ……ってなりました。恥ずかしい*7。
さてさて長くなりました。gitにコミットした内容をもとに、いよいよパッチの提出……は、次の記事にて。
*1:同様の理由で、 公式Wikiの開発情報のページ翻訳するの昔は抵抗があるんですよね……。 Readmeなんかで使ってるMediaWikiの翻訳プラグイン適用してくれないかなー。 そしたら原文更新されたパラグラフは英語になるので、うっかり古い情報を提供せずに済むので。
*2:プロジェクトの日々を知ることができるサイト https://dashboard.documentfoundation.org/ によれば一日当たりだいたい300弱のコミットがあるらしいですね。
*3:回帰ともいう。つまり、変更によって過去に動いてた機能が動かなくなったなど。
*4:今この記事を書くために再度読み直したらそんなに大変じゃないかも……。 たぶん [$-804] がExcel用の言語コードなので、生成されたXLSXをunzipして中のXML覗いて、これだけ直してあげればよさそう。 それで日本語・韓国語のテスト用ODSを作ってあげさえすれば。 レビューで指摘もらったら対応するかも。
*6:わたくしの場合はこのとき、masterからとってきただけのソースでも特定のテストがfailしました……この場合正しくは「どうなってるの？」とメーリングリストなりなんなりで聞くべきなのですが、わたくしはとりあえず無視で先に進みました……よくない。
*7:自分でテスト実行した後、手作業でちょっとだけ直してコミットしたコードに誤りがあったのです。
