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:自分でテスト実行した後、手作業でちょっとだけ直してコミットしたコードに誤りがあったのです。
【野良翻訳】ミュンヘン市、「Public Money, Public Code!」にコミット
Free Software Foundatoin Eurpoe (FSFE)のブログ：
の野良翻訳です。
ミュンヘン市は新たな連立合意で「Public Money? Public Code!」（公金は公的コードへ）原則にコミット。FSFEは新市政におけるこの決定を歓迎し、実現の進捗を緊密に監視します。
ミュンヘン市のSPD*1 および緑の党は、3月の地方選を受けて、先の日曜日に連立協定に合意しました。 この中には、フリーソフトウェアの利用に対するポジティブな声明が含まれています：将来において「Public Money? Public Code!」原則が適用されるべきとのものです。 ミュンヘン市はこうしてFSFEからの要求に加わりました。
「FSFEはミュンヘン市政による「Public Money? Public Code!」ポリシーを歓迎します。 先のSPDとCSU*2による市政は、 それ以前の革新的なフリーソフトウェア戦略から距離を置いていましたが、今や再びポジティブなシグナルが灯りました。 政府組織が「Public Money? Public Code!」原則に従うことは、ほかの公的団体との共同作業に利益となり、特定のベンダーからの独立を保ち、税金を節約できる可能性があり、イノベーションを進め、ITセキュリティのより良い基盤となります。」 と、Free Software Foundation Europe議長、 Matthias Kirschnerは述べました。
2014年、SPDはCSUとの連立合意に加わり、Dieter Reiter (SPD) が新しいミュンヘン市長として当選しました。 ミュンヘン市は、独立したフリーソフトウェアとGNU/Linuxオペレーティングしシステムに基づくITインフラストラクチャを開発する、 「LiMux」戦略を放棄し、プロプライエタリなソフトウェアへの依存への回帰を始めました。Free Software Foundatoinはこの「再移行」を過去に批判しました。 今、SPDと緑の党による新たな合意によって、ミュンヘン市は彼らによる「Public Money? Public Code!」へのコミットメントに戻ろうとしているように見えます。 依然として、協定は、たとえば個人情報や機密情報が含まれていないソフトウェアに限定するなど、いくつかの典型的な抜け穴があり、改善の余地があります。 そのためFSFEは彼らの「Public Money? Public Code!」ポリシーの実施および、将来において調達手続きがどのように行われるかに対する緊密な監視を継続します。
「Public Money? Public Code!」イニシアチブは、フリーソフトウェアを、公的に投資されるソフトウェアの標準とするということを目標としています。 Free Software Foundation Europeは、180の市民団体および、27,000人の個人とともに、オープンレターに署名しました。 この署名をもとに私たちはヨーロッパの政策決定者、政府代表者に連絡を取り、公的なコードを標準とすることを説得しています。 より大きな影響を与えるために皆さんにも署名を呼び掛けています： https://publiccode.eu/
