2014-11-02

はじめてのLibreOfficeソースコミット

2014.11.05 追記：とても重要な参考資料を紹介するの忘れていたので後ろにくっつけます。見てくださいね。

私は口先野郎なので、「LibreOfficeの日本コミュニティに一番必要なのはコード書く人。オープンソースはコード書く人が正義*1」とか言っていながら、自分はぜんぜんコード書いてなかったんですよね。これでも元はプログラミングでおまんまを食べてた人間として、これはいかんよなーってずっと考えてた。

開発に挑戦することに対してはいろんなハードルがあるだろうけど、LibreOfficeの場合はコードベースも巨大だしコミュニティもいろんな人が関わってるのでそれなりのお作法もある。正直、どこから手を付けていいかわかんないところがあります。で、私的には、もちろん開発そのものの難しさもあるけれども、それ以前に、とにかく自分の修正のパッチを送ってレビュープロセス通してって、人が介在するところに心理的に抵抗があったわけです。英語では丁寧にドキュメント化されてるのだけど、私英語得意じゃないしね。

で、これは誇っていいことだと思うんですが、LibreOfficeにはEasy Hacksという「開発入門者のための誰でも直せそうなバグ」をタグ付けしたものがあって、もうほんっとに簡単なバグ（で、緊急性が高くない奴）とかを元に、修正してコンパイルしてレビューシステムにpushしてレビュー受けて、ってことをできるようになってる。よし、これにチャレンジしようと。

LibreOffic Conference 2014 Bernのときから初めて、ついついサボってたのでこれはイケナイと思い立ち、自分の尻叩きのために関東LibreOfficeHackFest(#1) with 第119回東京エリアDebian勉強会というイベントをやって*2 ようやっと目鼻がつき、こないだ送ったパッチは無事に取り込まれました。

すっごいしょぼい修正で恥ずかしいのですが一応コミッター*3 の仲間入りをしたので、記録として残しておきます。

課題の選定

Easy HacksはAll LibreOffice Easy Hacks by required Skillというページで必要なスキルごとに分類されているんですが、今回は曲がりなりにも昔はそれでご飯食べてたC++の、超簡単レベルな奴からピックアップ。

Bug 43157 - Clean up OSL_ASSERT, DBG_ASSERT, etc.

Bug Descriptionから引用すると：

The assertion/logging functionality from osl/diagnose.h (OSL_TRACE, OSL_ASSERT, OSL_ENSURE, OSL_FAIL) and tools/debug.hxx (DBG_ASSERTWARNING, DBG_ASSERT, DBG_BF_ASSERT, DBG_WARNING, DBG_WARNING1--5, DBG_WARNINGFILE, DBG_ERRORFILE) is obsolete and needs to be cleaned up:

To assert invariants of the code (that can only be violated if there are programming errors) use standard C/C++ assert.

To log warnings about unusual events (that the code nevertheless needs to handle in some way, like malformed input or I/O failures), use the SAL_WARN... macros from sal/log.h.

To log other information useful for debugging, use the SAL_INFO... macros.

See https://wiki.documentfoundation.org/Development#Assertions_and_Logging, the mail thread at http://lists.freedesktop.org/archives/libreoffice/2011-November/020864.html, and the documentation in the sal/log.h header for further information.

要は古くて非推奨になったアサーション・ロギングマクロを、今のスタイルに書き直しましょう、ってだけ。機械的な置換でいけそうだからこれなら自分でもできるやろと。

ビルド環境構築

まずはgitでソースコードをまるっと取って来ます。で、ビルドに必要なライブラリをがっと取ってきて、一回ビルド通します。LibreOfficeのフルビルドは環境にも寄りますけど数時間かかるので、ビルド投入して寝ちゃうのがいいでしょう。

$ git clone git://gerrit.libreoffice.org/core LibreOffice
$ sudo apt-get build-dep libreoffice
$ cd LibreOffice
$ ./autogen.sh --enable-gstreamer --disable-gstreamer-0-10 --with-lang="ALL"
$ make

ビルド終わったらちゃんと動くことを確認します。

$ instdir/programs/swriter &

ヘルプ→LibreOfficeDevについて、を確認。

大丈夫そうですね。

コードの修正

今回の修正は色んなところのソースをお掃除しましょうというネタなので、どこ直してもまあいいわけです。なので直せそうなところをgrepで探しましょう。

豆知識としては、LibreOfficeはビルド時に依存するライブラリのバージョンを固定するために、サーバーにおいてあるtar ballを落としてきてworkdir/UnpackedTarballというところに展開します。その他yaccの生成物とかもあるので、単にgrep -r するとそういうのがいっぱい引っかかってしまうので、git grep使うほうが100倍ぐらい賢いです。
ということで、git grep OSL_ したら、あるわあるわ。どれ直してももちろんよいのですが、一部のソースは特定のconfigureオプションをオンにしないとコンパイルされない（そして、そのconfigureオプションはほとんど誰も使っていない）とかある*4 ので、ちょっとだけ注意が必要です。今回は pyuno/source/module/pyuno.cxx というソースを直すことにしました。変更が2行しかないのでｗ

ターゲットが決まったらまずは作業ブランチ切りましょう。

git checkout -b work

修正はバグ票にあった他のコミットを見ながら、こんな感じに書き換えればいいのかなと*5。

--- a/pyuno/source/module/pyuno.cxx
+++ b/pyuno/source/module/pyuno.cxx
@@ -66,7 +66,7 @@ void PyUNO_del (PyObject* self)
 
 OUString val2str( const void * pVal, typelib_TypeDescriptionReference * pTypeRef , sal_Int32 mode )
 {
-    OSL_ASSERT( pVal );
+    SAL_WARN_IF( !pVal, "pyuno", "pVal != NULL" );
     if (pTypeRef->eTypeClass == typelib_TypeClass_VOID)
         return OUString("void");
 
@@ -124,7 +124,7 @@ OUString val2str( const void * pVal, typelib_TypeDescriptionReference * pTypeRef
         buf.append( "{ " );
         typelib_TypeDescription * pTypeDescr = 0;
         TYPELIB_DANGER_GET( &pTypeDescr, pTypeRef );
-        OSL_ASSERT( pTypeDescr );
+        SAL_WARN_IF( !pTypeDescr, "pyuno", "pTypeDescr != NULL" );
 
         typelib_CompoundTypeDescription * pCompType = (typelib_CompoundTypeDescription *)pTypeDescr;
         sal_Int32 nDescr = pCompType->nMembers;

で、make。フルビルド済ませてあるので、今度はそんなにかからないです。本当はmake checkでユニットテストも通すべき（そもそも、このコードにユニットテスト書くべき）なんですが、私が作業したときのmasterはなぜかmake checkすると通らない（よくあることのようです ^^;）ので、うーんと悩んだ末そのまま。

とりあえず、ローカルの作業ブランチにコミットしておきます。コミットコメントはこんな感じ。バグ修正のときはバグ番号を書くのが決まりです。

fdo#43157 - Clean up OSL_ASSERT, DBG_ASSERT
    
- Clean up OSL_ASSERT

gerritの設定

LibreOfficeでは、Googleが開発したソースコードレビューシステムGerritを使用しています。gerritの持つgitリポジトリにpushすると、その上でdiffを確認しつつ、レビューコメントがついたり質疑応答したりできるシステムです。ビルドbotも走っていて、そのコミットでビルドがぶっ壊れないかも確認してくれます。超便利。MLにパッチ投げて議論して、ってのもいいけど、gerritを使うほうが推奨されてる……はず。

ので、まずはgerritの設定するところから始めます。TDF WikiのGerritの解説ページを見ながら。

最初は https://gerrit.libreoffice.org にてアカウント作成ですが、これは大昔にやったことがあったので省略。Googleアカウントがあれば簡単だった記憶が。で、アカウント設定でgit push用のssh公開鍵を設定しておきます。もちろん専用の鍵ペア作ってもかまいません。

次に、解説ページによると、

You must set your username to match your freenode IRC nick (see 'Username' in your gerrit account settings).

とあるので、freenodeのNick登録しなきゃいけません。IRC技能が低い私はここでしばらく調べまわったのですが、自分 irssi 使ってるので、

/msg NickServ REGISTER <password> youremail@example.com

しといて、

/NETWORK ADD -autosendcmd "/^msg nickserv id <username> <password>;wait 2000" Freenode

でFreenodeのNickとGerritのアカウント名を合わせればいい……のかな。今んとこそうしてます。ただ、irssi常時上げてるわけじゃないし、irssiもnotify上げてくれるわけじゃないので実のところIRCマトモに使えてない。なんかいい方法ないすかね。ま、それはまた別の話。

で、先の解説ページに戻りまして、手動セットアップします。まずは.ssh/configに：

Host logerrit gerrit.libreoffice.org
       IdentityFile /path/to/your/private-key
       User <username>
       Port 29418
       HostName gerrit.libreoffice.org

を追記。秘密鍵のところは、さっきGerritに登録した公開鍵とペアになる鍵を指定しましょう。当たり前ですね。

で、LibreOfficeのソースディレクトリに移動しておいて、

$ ./loggerit test

とやって、"Your gerrit setup was successful!" と表示されればOK。

さてgitにpush先を指定しておきましょう。

$ git config remote.origin.pushurl ssh://logerrit/core

これで準備完了です。

いよいよpush……の前に

なんだかんだで、ソースコードを修正してからココらへんの設定をのたのたやってたので、まる2日ぐらい経ってたのかな？

LibreOfficeは進化が早いソフトウェアなので、2日も経つと当然masterには大量に変更が溜まってる。まあ、ビルド通らなくなるとは思えないけど、もし同じファイルを修正した人がいたりしたら悲しくなるので、念のためmasterを最新にして、自分の変更をその先頭にぶら下げるようにしたい。

私、git力も低いので、ホントはこういうときってrebaseでできるのかもなあって思いつつ、悩んだ末masterをpullして最新にした後新たにブランチ切って、そこに作業ブランチの変更をcherry-pickするようにしました。いいのかなあ、こんなやり方で。

$ git checkout master
$ git pull origin master
<ぞろぞろとファイルが降りてくる>
$ git checkuout work
$ git log --oneline | head
<先頭は自分のコミットなのでハッシュ値を見ておく>
$ git checkout -b fdo43157 master
$ git cherry-pick <さっき確認したハッシュ値>
$ make
<ちゃんとmake通ってできたものが動くこと確認>

Gerritにpush

ドキドキしながらpush……してもいいのですが、いきなり投げるのはちょっと怖いので、なんか稽古場があった気がする……って読んだら、

<ローカルブランチ名>:refs/for/master の代わりに <ローカルブランチ名>:refs/drafts/master に投げるとドラフトとしてコミットできるよ

って書いてある。これはドラフトに一旦おいて議論するみたいな使い方をするところなのかなってのも思うのですが、まあ、突っ込んですぐ消すなら大丈夫かな、と……。

で、今の場合は：

$ git push origin fdo43157:refs/drafts/master

すると、「このURLに登録されたよ！」って出るので、そこを見に行くと、draftsにちゃんとコミットがあることが確認できる。

ホントは、このdraftsにadd reviewerしてレビュープロセスに移動するのが正しい使い方らしいのですが、誰をレビュアーにするとかプロセスがわかんなかったので、一度abandonして再度pushすることにしました。いいのかな。不安なので、みなさんはポリシー各自確かめてね。とにかくうりゃっとpush！

$ git push origin fdo43157:refs/for/master

すると、こんな感じで登録されます。あ、これレビューコメント色々もらって修正したやつなので最初とは変わってます。古いパッチも見られますけどね。最初にpushしたのはPatch 1。

pushしてしばらく経つと「ビルドbotが起動したよ」「ビルド成功したよ」とメールが来ます。ほっと一安心。あとは人間のレビュアーの登場を待ちます。

ライセンス宣言

おっと、ライセンス宣言もしないといけません。開発者・貢献者リストのページにあるとおり、開発者メーリングリストに：

All of my past & future contributions to LibreOffice may be
licensed under the MPLv2/LGPLv3+ dual license.

というメールを投げる必要があります。著作権譲渡や契約の締結などは不要です。めっちゃカジュアルですね。
本当は先の開発者リストWikiに自分の名前書かなきゃらしいのですが、このWiki超重要なので間違って編集したら怖いな、いわれたらやろうということで一旦保留*6。

レビュー指摘反映

さて、ドキドキしながら待ってたら、コメントがつきました。まずはTakeshi Abeさん*7からの二つのコメント。

SAL_WARN_IFの第三引数は「こういう状態だからおかしいよ」ってものをログに残すものだから、条件逆じゃない？
SAL_WARN_IFの第二引数に指定するログエリアはinclude/sal/log-areas.doxに定義しないとダメだよ。

二番目の指摘は完全に見落としだったんですが、最初の指摘は……私はなにを考えていたんでしょう。まあ、勘違いとしかいいようがないですね。お恥ずかしや。

次の指摘はバグ#43157のreporterでもあるStephan Bergmannさんによるもの。

これ両方とも、NULLだったら後ろ死ぬからワーニングじゃなくてアサートにすべきじゃない？

……むぐ。そりゃそうだ。何を考えていたんでしょうワタクシ。

言い訳するとSAL_WARN_IFとかを定義してるinclude/sal/log.hxxにはアサートに当たるものがなかったのと、同じバグ票に対するこちらのコミットだとOSL_ASSERTをSAL_WARN_IFに書き換えているコードがあったからというのはあるんだけど、それはプログラマー的には思考停止であって言い訳にもならん。あかんわ。

で、間抜けな私はあれ、アサートのマクロってなくない？どれ使えばいいんだろ？と動揺して、日本語メーリングリストで質問したら、「いやいやC++のassert()でいいでしょう」ってCalcハッカーのKohei Yoshidaさんから教えてもらった。……あ。そうだね。そりゃそうだ。というか、バグ票にも " To assert invariants of the code (that can only be violated if there are programming errors) use standard C/C++ assert." って書いてあるじゃんかー。頭悪いな。

ということで、assert() に直した奴を再度コミット。--amend でコミットするとChange-Id:を見て、同じgerritエントリーに登録してくれるとな。素晴らしい。ので、それをpush。えいっ。これがPatch 2。

再びレビュー待ち……そして。

またビルドbotからのメールを受け取ってドキドキしながら待ってたら、「いいみたいだね、でもassert()使うなら #include を明示的にするほうがいいと思うな。この場合は他のヘッダでincludeされてるから問題ないけどね」って指摘をもらった。けど、それは別途直しておくよってことでパッチはacceptされて、無事コミットは取り込まれました。わーい！

http://cgit.freedesktop.org/libreoffice/core/commit/?id=922f2005f34589e60969be3f2bf74e4af58e2e69

感想

仕組みはいろいろ良くできてる。ドキュメントが少し散らかってる感じはあるけど、ちゃんと読めばわかる。
Gerritすごく良くできてて感動。
みなさん大変親切でありがたや。お世話になりました。
次はもうちょっと機能や不具合に関わる修正に挑戦したいな。

参考資料：Tomofumi Yagiさんの発表資料 (2014.11.05追記)

LibreOfficeへのコミットについては、Tomofumi Yagiさんのスライドが非常に参考になるので紹介しておきます。私が書かなかったOpenGrokなどについても説明されていて、必読です。

LibreOfficeコミュニティに不具合修正パッチを送ってみた from Tomofumi Yagi

*1:あーもちろん、翻訳やアウトリーチ・プロモーションやその他の活動もやっぱり大事なんですよ。わかりやすいように極端な言い方をしてるだけで。

*2:タイトルの通り、東京エリアDebian勉強会の皆さんには大変お世話になりました。またコラボしましょう！

*3:LibreOfficeはgitで管理されており、誰でも1行からコミット可能なので、例えばApache OpenOfficeのように特定のコミッターという権限を持つ人がいるわけではありません。コードが取り込まれれば誰でもコミッターです。

*4:BernのHackNightで挑戦したのがうまく行かなかったのはこれが原因。

*5:あ、間違ってるってのは知ってるので、ちょっと待ってね。

*6:結局は、後述のStephenさんがやってくれました。

*7:LibreOffice日本語チームのメンバーで、アクティブにコミットされている安倍さん。

2014-08-28

SoftLayerでベアメタルインスタンスを借りてLibreOfficeをビルドしてみたよ

与太話 LibreOffice SoftLayer

小ネタ。

IBM印のクラウドサービスであるSoftLayerは仮想化によるインスタンスだけでなくベアメタルサーバーをダッシュボード上ぽちぽちで借りられることで有名ですが、今まではひと月ごとの貸出だったのでシャレで借りるにはちょっと高いなって思って距離置いて見てました。

でもなんか、ある日突然、時間単位課金が可能になってるじゃないですか。超びっくり。これは試すしかない！
最初は一番格安な2coreあたりを借りようと思ったんですが、とりあえずいっちゃん高いのってどれぐらいなんやろって思ってえいっと16core 64GBメモリを選んで価格を見てみたら、時間あたり$1.2ちょっと。ペットボトル1本分？じゃあシャレで借りてみるか、破産するほどじゃないだろ、ってことで借りてみました。

ベアメタルサーバーの振り出しは早ければ30分と言われてますが、ぼくの場合、たぶん高い奴を選んだからなのでしょう、申し込みしてからacceptに1時間ぐらいかかり、課金しますよって連絡にそれから2時間、さらにプロビジョニング終了って言われたのがさらに1時間後ぐらいなので、結構かかってますね。

借りてなにをやるかというと、LibreOfficeのビルドをベンチするに決まっていますｗ

とりあえず /proc/cpuinfo と /proc/meminfo 貼っておきます。

$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping        : 4
microcode       : 0x416
cpu MHz         : 2600.052
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5200.10
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping        : 4
microcode       : 0x416
cpu MHz         : 2600.052
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 1
cpu cores       : 8
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5200.10
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping        : 4
microcode       : 0x416
cpu MHz         : 2600.052
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 2
cpu cores       : 8
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5200.10
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

(中略)

processor       : 15
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping        : 4
microcode       : 0x416
cpu MHz         : 2600.052
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 7
cpu cores       : 8
apicid          : 15
initial apicid  : 15
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5200.10
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
$ cat /proc/meminfo 
MemTotal:       65942284 kB
MemFree:        47738556 kB
Buffers:          602552 kB
Cached:         15199592 kB
SwapCached:            0 kB
Active:         12728520 kB
Inactive:        3615036 kB
Active(anon):     544096 kB
Inactive(anon):      540 kB
Active(file):   12184424 kB
Inactive(file):  3614496 kB
Unevictable:        3708 kB
Mlocked:            3708 kB
SwapTotal:        999420 kB
SwapFree:         999420 kB
Dirty:             36740 kB
Writeback:           176 kB
AnonPages:        545164 kB
Mapped:             9476 kB
Shmem:               744 kB
Slab:            1394684 kB
SReclaimable:    1319144 kB
SUnreclaim:        75540 kB
KernelStack:        1656 kB
PageTables:         3644 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33970560 kB
Committed_AS:     613892 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      376288 kB
VmallocChunk:   34359354112 kB
HardwareCorrupted:     0 kB
AnonHugePages:    538624 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       78800 kB
DirectMap2M:     3031040 kB
DirectMap1G:    66060288 kB

16コアなのでえらいことになってるな。途中省略しました。

あーついでに uname -a も。

Linux XXXXX 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

で、LibreOfficeをさくっとビルドしましょう。まずはお約束：

# apt-get install build-essential git
# apt-get build-dep libreoffice

して、rootのままだとアレなので一般ユーザーにスイッチして、

$ git clone git://gerrit.libreoffice.org/core LibreOffice

してmasterを取ってくる。LibreOfficeにcdして、

$ ./autogen.sh --with-package-format="deb" --enable-epm --with-parallelism=16 --with-lang="ALL"

だ！ 16コアでメモリもうんとこさ載ってるので、とーぜん--with-parallelism=16である。
おっと、gstreamerがなんとかいって怒られる。そういやmasterでは使ってるgstreamerのバージョンが違うかなんかだったな。ということで、

# apt-get install libgstreamer0.10-dev libgstreamer-plugins-base-0.10-dev

としてもっかいautogen叩くと、OK、Makefileができた。
あとは：

nohup time make &

して、そのままほっといた。
で、帰る途中にご飯食べてお家帰ってお風呂入ってから確認したら、正常にmakeは成功してるっぽい。
nohup.logの末尾はこんな感じ。

[build CUS] instsetoo_native/install
[build BIN] instsetoo_native
[build MOD] instsetoo_native
[build MOD] libreoffice
[build BIN] top level modules: libreoffice
[build BIN] loaded modules: UnoControls accessibility accessories android animations apache-commons apple_remote avmedia basctl basebmp basegfx basic bean beanshell binaryurp boost bridges canvas chart2 cli_ure clucene codemaker coinmp collada2gltf comphelper configmgr connectivity cppcanvas cppu cppuhelper cppunit cpputools cui curl dbaccess desktop drawinglayer dtrans editeng embeddedobj embedserv epm eventattacher expat extensions external extras filter firebird forms formula fpicker framework glew glm graphite harfbuzz helpcompiler hsqldb hunspell hwpfilter hyphen i18nlangtag i18npool i18nutil icu idl idlc instsetoo_native io javaunohelper jfreereport jurt jvmaccess jvmfwk l10ntools lcms2 libabw libcdr libcmis libebook libetonyek libexttextcat libfreehand libgltf liblangtag libmspub libmwaw libodfgen liborcus libpagemaker libpng librelogo libreoffice libreofficekit librevenge libvisio libwpd libwpg libwps libxmlsec lingucomponent linguistic lotuswordpro lpsolve mdds more_fonts mythes neon np_sdk nss o3tl odk offapi officecfg oovbaapi oox opencollada openldap openssl package poppler postgresql postprocess pyuno qadevOOo readlicense_oo redland registry remotebridges reportbuilder reportdesign rhino ridljar rsc sal salhelper sax sc scaddins sccomp scp2 scripting sd sdext setup_native sfx2 shell slideshow smoketest solenv soltools sot starmath stoc store svgio svl svtools svx sw swext sysui test testtools toolkit tools touch tubes ucb ucbhelper ucpp udkapi unodevtools unoidl unoil unotest unotools unoxml ure uui vbahelper vcl vigra winaccessibility wizards writerfilter writerperfect xmerge xmlhelp xmloff xmlreader xmlscript xmlsecurity
[build ALL] top level modules: build-non-l10n-only build-l10n-only
[build ALL] loaded modules: UnoControls accessibility accessories android animations apache-commons apple_remote avmedia basctl basebmp basegfx basic bean beanshell binaryurp boost bridges canvas chart2 cli_ure clucene codemaker coinmp collada2gltf comphelper configmgr connectivity cppcanvas cppu cppuhelper cppunit cpputools cui curl dbaccess desktop drawinglayer dtrans editeng embeddedobj embedserv epm eventattacher expat extensions external extras filter firebird forms formula fpicker framework glew glm graphite harfbuzz helpcompiler hsqldb hunspell hwpfilter hyphen i18nlangtag i18npool i18nutil icu idl idlc instsetoo_native io javaunohelper jfreereport jurt jvmaccess jvmfwk l10ntools lcms2 libabw libcdr libcmis libebook libetonyek libexttextcat libfreehand libgltf liblangtag libmspub libmwaw libodfgen liborcus libpagemaker libpng librelogo libreoffice libreofficekit librevenge libvisio libwpd libwpg libwps libxmlsec lingucomponent linguistic lotuswordpro lpsolve mdds more_fonts mythes neon np_sdk nss o3tl odk offapi officecfg oovbaapi oox opencollada openldap openssl package poppler postgresql postprocess pyuno qadevOOo readlicense_oo redland registry remotebridges reportbuilder reportdesign rhino ridljar rsc sal salhelper sax sc scaddins sccomp scp2 scripting sd sdext setup_native sfx2 shell slideshow smoketest solenv soltools sot starmath stoc store svgio svl svtools svx sw swext sysui test testtools toolkit tools touch tubes ucb ucbhelper ucpp udkapi unodevtools unoidl unoil unotest unotools unoxml ure uui vbahelper vcl vigra winaccessibility wizards writerfilter writerperfect xmerge xmlhelp xmloff xmlreader xmlscript xmlsecurity
50434.17user 2769.59system 1:20:07elapsed 1106%CPU (0avgtext+0avgdata 887460maxresident)k
42904inputs+66557720outputs (299major+781442922minor)pagefaults 0swaps

まあビルドログはいいとして、ビルド時間は1:20:07ってこと？
私Linux力弱いんで読み違いならすみません。まあ、そこそこ早いかなって思います。

とっととサーバー落とさないとお小遣い減っちゃうのでこんなとこで。小ネタで失礼しました。んじゃ！

2014-06-08

LibreOffice mini Conference 2014 Tokyo/Japan 開催してきた

Event LibreOffice

写真とか撮ってないので（日本語チーム内にカメラ趣味の方がいらっしゃるので、その人にカメラマンはお任せした）ダラダラと日本語でレポートを*1。

そんなわけでLibreOffice mini Conference 2014 Tokyo/Japan無事終了しました。

当日のイベントの模様はtogetterにまとめたので、そちらも併せてご覧いただくと幸いです。

最初にお礼

まず、オフィス移転前の忙しい中に無理をいって素晴らしい会場を提供してくださったIIJの山田さんには大変感謝しております。

そしてCfPに応募して、楽しい話をしてくださったスピーカーの皆様、LT参加者の皆様。とりわけ遠く沖縄からわざわざ参加してくださったLibreOfficeコミッターである安倍さん（身内だけど、ありがたいことはありがたい）。

それからもちろん、足の悪い中参加してくれ、楽しんでくれた皆様（スタッフも含めだけど31名の登録がありました。素晴らしい！）。

個々の仕事が忙しい中、イベント開催に向け努力してくれたLibreOffice日本語チームの皆にも感謝感謝です。

個々のトークダイジェスト

このイベント、OSC東京のサブトラックとしてやった奴に続き二回目なのですが、前回はコミュニティ内でスピーカーを決めてしまって一般応募ってかけませんでした。それじゃあカンファレンスっぽくないよね？ということで、今回はちゃんと発表者募集（CfP）を呼びかけることにしました。これは安倍さんのアイディアだったはず。

ということで、今回のスピーカーはちゃんとCfPに応募して採択された方々です。なお採択されなかった奴もあるので（後述）出来レースではありません。次回はもっと広くスピーカーが増えてくれるといいな。

さてそんな中で選ばれた皆さんをダイジェストでご紹介。

日経LinuxのLibreOfficeマクロの記事で有名な谷さんは、「LibreOfficeマクロのサンプル紹介と解説」と題して、その連載の裏側と意図、そしてサンプルプログラムの解説とデモをやっていただきました。なお谷さんの連載は日経Linuxのムック：

これ1冊で完全理解 Libre Office (日経BPパソコンベストムック)

作者: 日経Linux
出版社/メーカー: 日経BP社
発売日: 2014/04/09
メディア: 単行本
この商品を含むブログ (1件) を見る

にも一部（連載第１回だけかな？）再録されているので、お手元にある方はぜひ。

ついでLibreOfficeコミッターでありTDF及びLibreOffice日本語チームメンバーである安倍さんから、「LibreOffice開発版のビルドのチュートリアル for Linux/Mac OS X」と題してハンズオン形式のセミナーが行われました。なにせLibreOfficeのビルドは時間がかかることで有名ですが、autogen.shを通してmakeが走りだすところを目標、というのはよい着地点だったと思います。イベント終了後、TwitterやMLなので「ビルド終わったよ！」という報告を何件か受けてありがたい限りです。

私の発表はその補足という形で、Windowsでビルドしたい人に向けて一応の道筋だけは示しておこうという「LibreOffice開発版のビルドの基礎 for Windows」というお話でした。といっても私自身Windowsを常用してないのでよく分かってないことが多々あるのですが、一応資料は公開しているのでどぞ。

The Basic of How to build LibreOffice / LibreOffice開発版ビルドの基礎 for Windows from Naruhiko Ogasawara

その次はわざと1時間近い休憩を取って、参加者同士の交流したり雑談したり……という時間にしたつもりだったんですが、つい欲張ってそこでLTやったらみんな聞き入ってくださり、本来の交流タイムという意味ではちょっと微妙……でもLT楽しかったし、結果オーライでいいかということで。

LTについては妹尾さんの「LibreOfficeを使う理由〜他のソフトと比較して〜」（資料はイベントページに上がっています）、中本さんのOOo時代のビルドの話とそれが今にどうつながってるかという話、日本openSUSEユーザー会武山さんによるLibreOfficeのフォントマッチングをなんとかしたい話、近藤さんの「Web3.0時代のLibreOffice」、そして私のEasyHacksネタということで、どれも面白かったです*2。あ、びぎねっとさんドラの貸出ありがとうございました。

EasyHacksネタは本来はCfPに出したのですが不採択になり*3 LTになったというものでした。この資料はこちら。

What's EasyHacks? / EasyHacksについて from Naruhiko Ogasawara

(2014.06.08時点では思い切り書き間違えてますが）「EasyHacksは開発入門の手段であって目的じゃない」のはホントにそう考えていて、うまいことEasyにHackできるものを見つけたらそれやればいいし、できなかったら自分にとってEasyな問題を解決できればいいよねと思います。

さてLT＆休憩終わって次はRyo Onoderaさんの「pkgsrcを使った*BSDでのLibreOffice 4.2のビルド」。これは面白かった！今回開発よりということでイベントを仕込んだんですがこの発表は特濃。各 *BSD のビルドシステムの特徴入門みたいにもなっておりすごい労作でした。正直、Onoderaさんにはminiconfといわず世界のLibreOffice Conferenceで発表してもらいたいです。絶対みんな面白がると思います。この資料もイベントサイトにすでにアップロード済なのでぜひご覧アレ。

トリはLibreOffice日本語チームの榎さんによる「品質を高める活動に参加してみよう！」ということでLibreOfficeの品質保証(QA)についてのさまざまな取り組みを紹介するトーク。色々とこうしたらいいんじゃないかというアイディアは出ているのですが現状人出が足りなくて……というのがLibreOfficeのQAの現状という認識なので、それが簡潔に俯瞰できるよい発表でした。きっと榎さん自身がレポート書いてくれるでしょうからそれに期待。

お茶タイムとか懇親会とか

今回、昼は「500円払えばコーヒーまたはお茶*4 飲み放題、ケーキも食べていいよ」ということで、ソラマチのチーズケーキ屋さんからケーキを仕入れ、コーヒーはIIJさんと同じビルのタリーズに注文して持ち込みました。前述のように「まとまったお茶タイム」が取れなかったのが少し残念ですが、まあ、好評だったと思います。収支はやや赤字かな？まあ、いいです。いい感じのケーキ屋さんをまだ発見できてないので毎回私がイベントをやるたびにチーズケーキになってしまうのが難点なので、われこそはという人はケーキ買い出しを手伝っていただきたく。

懇親会は神保町駅を少し過ぎて水道橋のほうにある中華料理屋。スタッフ間の意思の疎通が取れてなくて会場間の移動でちょっとアレ？という感じになりましたが、まあ子どもではないのでみんな無事にたどり着きました。飲み食べ放題で3600円は安いなあ。いろんな話ができて楽しゅうございました。

KPT

最後にスタッフ視点のイベントレポらしくKPTでもやっておきますかね。

Keep

Call for Presenter をやったのはよかった。LTもギリギリまで募集したのはよかった。
IIJさんの会場は最高だった。
お茶タイムを用意したのはよかった。
ハンズオンのゴール設定がちょうど良かった。

Problem

当日に顔合わせるからそこで決めればいいよね、と思ってたことが、意外と時間なくてすり合わせが不十分だったことがけっこうあった。もっと早目に集合したほうがいいのかなぁ……。
当日動ける人間がもっと欲しかった。
コーヒーを飲めない人が一方的に割り勘負けする現状はあんまりよろしくないのでは。
タイムキープがいい加減でみんな時間超過してた。
懇親会会場への移動はスタッフ間の意思疎通がなさすぎ(^^;

Try

年内、LibreOffice Conference が終わったあとぐらいにもう一回やる？？
目指せ集客50人！そして100人！
当日だけ手伝って！というボランティアスタッフを募集しても良かったね。
チーズケーキ以外のお菓子が欲しい。
コーヒー以外のドリンクをどうやって調達するか。
タイムキープは「あと5分！」とか札出すとかして積極的に時間を守ってもらうようにするのがいいかな。
私なんかが持ってる告知ルートだとエンジニアの方にリーチしやすいけど、エンドユーザー向けのイベントやるとしたらどうやって告知する？
マルチトラックでfor Devsとfor Usersとかできたらいいね！
2日開催にして土曜日セミナー、日曜日もくもく会とかでも面白いかも。
私だけがいつもいってるけど、いつかはアジアカンファレンスを実現したいね！

終わりに

まあなんだかんだいってしんどいこともあったけど楽しかったです！みんなありがとー！

今までちょっとイベントに一生懸命で、次期リリース4.3に向けて作業があまりできてなかったこともあるので、これからはそれを頑張ります。
もくもく会を6/16(月)に企画したので、来れる人は来てね！翻訳とかQAのやり方、お教えします。

*1:英文ブログの方には写真収録するつもりなので、もし見たい奇特な人はそっち見てね。

*2:というと自画自賛にもなってしまうけど、私のはFacebookで中本さんに褒めてもらいましたから。まあいいやということで。

*3:正確にいえば、落としたのは私自身。だって他の発表を聞きたかったんだもん。

*4:といいつつコンビニのペットボトルのお茶だったのが不評らしく、残って持って帰ることになりました。

2014-05-31

カーネル読書会 #111 に参加してきた

Event

ちょろっとレポ。国内のイベントレポを書くのは超久しぶりな気がする。

LTしたんだけど私のLTには珍しく資料公開はしないので、エッセンスだけ書いとこうと思って。
全体的な話はよしおかさんのブログ読んでね。

LTの内容

まあLinuxCon Japanはスピーカーをやるのが多分一番面白いんだけど（やったことないが）その次に面白いのは絶対ボランティアなので、みんなボランティアやろうぜということがいいたかっただけ。

イベントをよいものにするという挑戦が面白いので、どうやったらみんなが満足してくれるかを考えて自律的に動く、それがまた面白いんだよね。あとスピーカーと浅く広く知り合いになれるのはやっぱ楽しいよ。

日本のLinuxCon Japanのボランティアのクォリティは世界一だと思うので、世界一のチームに入って最高のイベントを演出してみたいなと思う人はぜひ、来年のLinuxCon Japanのボランティアやりましょうね！

ついでにLibreOffice mini Conference 2014 Tokyo/Japanの宣伝もしましたよ。短縮URL http://j.mp/LibOminiJP14 も取ったのでよろしこ！

他のみなさんの発表

中島さんのDockerでPaaSなLTについてはやっぱDokkuとあとFrynnに興味を惹かれましたねえ。前者はそこそこ聞いたこともあるし試すのも簡単そうだけど、Frynnについては全然知らなかったので、調べてみたいねー。

中井さんのDockerの話については、みんなとりあえずコンテナ型仮想化の話をしてる段階で突っ込みすぎだと思いましたｗ
DockerはGNOME.Asiaのイベントでも聞いて思ったのですが、元々のユースケースとしてはDebianのpbuilderみたいなビルド・テスト用のクリーンルームをより簡単に作る仕組みであって、そのユースケースに併せて凝って作るよりぱぱっと作っちゃった印象があって、その道具立てがLXCでありaufsなのかなというのが私の理解なんですね。なので、LXCの話をするならDockerの回じゃなくて別のところでちゃんとやってほしいなあって思ったんですが、それは参加しておいて贅沢ですね。

あ、でも、今はDockerはaufs使ってないとか、ネットワークネームスペースの話についてはほうほうなるほどと思いました。

あと正直おっちゃんにはスライドの字が小さくて辛かったんだけど、あれは後でスライドダウンロードして見てちょうだいということだと理解しました。ので後で読みます。はいはいはい。

そんなわけで

主催のよしおかさん、会場提供のビットアイル杉野さん、その他いろいろ遊んでくれた皆さんありがとでした！

2014-05-31

GNOME.Asia Summit 2014 & FUDCON APAC 2014

Event LibreOffice OpenSource

こないだ北京行ってたのはこれ参加するためだったんですねー。

詳しくは公式サイトを。会場は北京にある北京航空航天大学でした。

面白かったことをダラダラ書きます。

Keynote: Keynote - Computing, Freedom and Privacy - Richard Matthew Stallman

ということでRMS御大のプレゼン。生RMS御大初めて見た！

内容はアンチプロプライエタリ、アンチDRM、そしてアンチJavaScript（サーバ側から引っ張ってくる場合のことかな？）、アンチSaaS（サービスだけを提供されてしまうとソースコードが参照できないという意味でプロプラと同じ）、という感じでした。いずれにせよ自由ソフトウェアの自由を阻害するものはすべてNGという内容のブレなさ。まあ、FSF/GNUのいつもの論調なので、ここで繰り返すのはやめておきます。

もっとキツい物言いする人かと思ってたら、ジョーク混じりで講演は和やかに進みました。言ってることは猛烈に過激なんだけどね。「プロプライエタリなソフトを生活のために書くな、お前は生活のためなら子どもの飲むミルクに毒を入れる仕事をするのか？」みたいな。

他のスピーカーはミネラルウォーターで講演する中、特別に煎れてもらったと思しき中国茶を飲みながら講演するRMS御大、さすがの風格でございました。

終わった後ステッカー配布されてたので50cmぐらいまで接近したんだけど緊張のあまり声かけられなかったよｗ

Building Orchestration and Configuration with Ansible at Fedora Project - Aditya Patawari

Adityaはインドから来たFedora Infrastructureチームの人。これは結構面白かった。

Fedora Infraチームは今Puppetで管理されてるサーバを徐々にAnsibleにしてるんだって。理由はAnsibleがAgentlessであるということが大きいとか。あとAnsibleのPlaybookの記述形式であるYAMLの可読性が高いのが、決してプログラマーではないインフラチームにはよいんだそうな。

現在PuppetスクリプトからAnsible Playbookへの書き換えをしてくれる人募集中なんだそーで、「入門編にいいスクリプトもあるよ」とのことなので、FedoraユーザーでAnsibleに興味がある人はトライされてみては如何。

Next Generation Input methods - Daiki Ueno, Anish Patil

IBus UI開発者のAnish Patil氏とエンジン開発者のDaiki Uenoさんによる次世代IMの話。なおDaikiさんはぼくを除くとGNOME.Asia唯一の日本人でした。

UI/UXの方はあんま覚えていないのだけど、IMエンジンを使わない、例えば英語のような言語においても、携帯端末で採用されてるようなauto completionを提供するにはどんなUXがいいのか、それって携帯と同じじゃまずいよね（携帯とデスクトップだとスペースの持つ意味が異なるし……）みたいなことを話していたような気がする。あとcompletionに用いる辞書の重要性とかね。ネットで鍛えたりするのがいいのかなーみたいな話をしていた気がする。

Daikiさんの次世代IMのアーキテクチャーの話は「俺達は別にまたIBusを捨てて新しいIMをつくろうってんじゃないんだ。ただIBusの良くないところをrevolutionしたいというだけ」って言葉から始まりました。

プレゼンは絵入りでわかりやすかったんですが絵をかくのめんどくさいので言葉でかいてしまうと：

SCIMみたいな古いIMはGTK immodule以外は全部シングルプロセスでUIもエンジンもまるごと動いてた。だから軽量だったけどどこか一部分でも死ぬとIM全体が死んでしまう。
IBusはそれに対し、UIとか各エンジン（日本語とかピンインとかハングルとか）を全部プロセスに切り分けて、D-Busで通信してた。これによってシステムが頑健にはなったけど、例えばハングルみたいなシンプルなエンジンまでもがキーイベントの一つ一つに対してプロセス間通信のオーバーヘッドが発生して遅くなるって問題がある。あとプロセス管理がいまいちで、新しいエンジンを入れてもibus-daemonを再起動しないと認識しないとか、テストコードのカバレッジが30％ぐらいしかないってのも問題。
だから次世代IMではIMライブラリというのを内蔵して一部のシンプルなエンジンはその中に抱き込んでしまって高速化する。パネルUIも一緒にしてしまう。ピンインや日本語入力のような重たいIMだけ外に切り出す。

てな話だったかな。で、それのサンプル実装としてlibtextinputってのがあって、これはWayland用のIMのプロトタイプで、IBusのエンジンの一部、WIPと呼ばれる部分を再利用しているんだそうな。

まあIBusについては正直いろいろ意見があったところで大変だとは思うけど、IMは我々日本人がPCを使う際に欠かせないモジュールだから、頑張ってほしいねい。

Keynote: A perspective for systemd: What has been achieved, and what lies ahead - Lennart Poettering

すごい盛り沢山なトークだったんで手短に紹介できないｗまあsystemdについては国内でもいろいろ資料があるわけで特段私が書かなくてもいいと思うけど、「単なるinit代替」だとは彼らは認識してない（もしそうだとしたら何でもかんでも盛りすぎ）って印象を強く受けました。コンテナ型仮想化が流行るとコンテナインテグレーション取り込むとかね。

あと、「別にFedora/RedHatのものではないし、特定のプロダクトをゴールにして開発してるわけじゃないよ」ってのは言ってましたね。それに「特定の環境だけをターゲットにしてるわけじゃなくて、サーバーもデスクトップもモバイルも組み込みも、ありとあらゆるもので使われることを目標にしてる」だって。

'CD' using Docker - Gerard Braad

このトークは面白かった……話術がｗ
彼はThoughtWorksのコンサル（今？元？）だそうで、弁が立つのも当然といえば当然か。質問したら：

The Thoughtworks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)

作者: Roy Singham,Martin Fowler,Rebecca J. Parsons,Neal Ford,Jeff Bay
出版社/メーカー: Pragmatic Bookshelf
発売日: 2008/03/01
メディア: ペーパーバック
クリック: 6回
この商品を含むブログ (2件) を見る

この本もらったよ。

ふむなるほど、って思ったのは、「普通CDっていうとContinuous DeploymentとかContinuous Deliveryの略っていうじゃん？でもそれ辞めようぜ、そもそもDeployとDeliveryってレベル違うしさ。だから俺はConsistent Developmentの意味でCDって言葉を使うよ」っていってた。

CIの話はわかるよね。SCMにソースコード入れるとビルドが走ってOKならテストしてその結果を開発者が見てまた直してSCMにチェックインして……をぐるぐる回す。サイクル。Travis-CIとかJenkinsとかGo.CDとか。

これを回すだけじゃなくて、商品開発という大きなプロセスの中だと、ビルドができてテストしたものを例えばテスター部隊に渡す。あるいは顧客に渡す。ってのが出てくる。上のサイクルから枝分かれしていく。この枝分かれをconsistentにできる仕組みの一つがDockerだよと。

Dockerの何がいいってLXCを使ってて軽量なこと。普通の仮想化でインスタンス振り出す時間が惜しいから。もちろん、aufs使ってて*1 バージョニングができることも嬉しい。

Dokkuの説明もしてた。DokkuはDockerとは粒度が違うシステムだけど、高〜いHerokuを使わなくていいのがいいよね！だって。ｗ

質問として、LXCであることがいいならDockerじゃなくて例えばVagrant-LXCでもよくない？っていったら、そっちはあんまチェックしてない、VagrantはVirtualBoxで遅いから好きじゃなくて見てなかった、って答えだった。私としてはVagrant-LXC気になるんだよなー。自分で調べるかー。

ちょっと青年の主張とか

主に宴会とかですごくいわれたのが「なんで日本からもっと人が来ないんだい？」ってことでした。私もGNOMEな人間じゃないけど、アジア最大のデスクトップなイベントなのでもう少し日本人いてもいいなとは思った。まあ、北京って距離は近いのだけど思ったより東京から行きにくいので（いい時間に飛行機がないので、土日でイベントに参加したければ金曜・月曜を休まないといけない）しょうがないのかもしれないけど、少しさみしいねえ。というか、FUDCON APACも兼ねてるわけですが、Fedoraの日本コミュニティってどうなってるんでしょうか？とか。

というかLibreOfficeもデスクトップアプリなわけだから、LibreOfficeコミュニティももっとコミットするといいんじゃないかなって思いました。

あともうひとついわれたのは「GNOME.Asia日本でやろーぜ！」でした。これ、単にみんな日本に来たいからじゃねーかｗって気がしますけど、実際、日本の事情ってどうなん？ってのはみんな気にしてましたね。そもそもデスクトップ分野にはコミッターも目立たないし。「みんなKDEとか使ってるの？」とかいわれたけど、いや実際コミッターがいないだけだと私は理解してますが。翻訳やってらっしゃる方はいらっしゃるので、アクティビティはそれなりにあるわけですが、見えにくいんだろうなあ。

「お前LibreOfficeのコミュニティの人間なんだろ？だったらLibreOfficeと一緒のイベントにすればいいじゃん」「今回FUDCONと一緒にやったように、いろんなディストロのコミュニティとやればいいだろ」ってアドバイスっつか煽り文句もいただいたです。実際、アジア地区のLibreOfficeイベントは私もやりたいと思っているので、一緒にやりたいと思う人、ぜひコラボしましょう！

その他小ネタ

実は海外あまりいったことないので、当然のように中国本土初上陸。北京おもしろいねー。私の好きなカヤックビデオ「One World」というのにアフリカを称して「Everything is powerful, big」っていってるのがあったけど、そんな感じ。何でもかんでも巨大でパワフルで、でもちょっと雑というかいーかげんというか。交通ルールの無法具合は目んたままんまるになりました。

英語通じないのはちょっとつらかったけど、まあ面白かったのでいいよね。途中で学習して、メモとボールペンを必ずすぐ取り出せるところに入れておくようにしました。漢字なら多少は通じるからね。でもホテルのカウンターで英語ダメ（できる人もいるんだけど、その人がシフトから外れてるときに私がチェックアウトしようとした）なのはちと困ったね。

あと写真を少々。

えーとこれは地下鉄のホーム。こうやって駅の図が出てるからどっち乗ればいいとかすぐ分かって安心。

これはランチを食べたお店。ここ以外入った店は言葉が通じなくてシステムがわかんなくて断念したのだ。情けなや。

食べたのはピリ辛麺類。美味しかったよ。

これは電気街のビルディング。中は寂れっぷりが半端無かった。実は買い物したのは別のビルなんだけど写真撮るの忘れちゃった。そっちはアジアな感じな熱気に溢れてました。そこでSIMを探すつもりが言葉が不自由で見つからなくて、結局モバイルWifiごと買いました。無駄遣いだけど、ま、そういうのも楽しみだからいいのだ。

で、これは泊まったホテル。安モーテルですな。

さて本番なのですが、私セッションとブースの写真全然撮ってないので、tiansworldさんのflickrアルバム「FUDCON APAC & GNOME Asia Summit 2014」から何枚か写真を拝借します。

https://flic.kr/p/ntDnh3
入り口にはこんなでかいポスターがあって、初日はその正面に受付がありました。二日目からは受付は右手に移動し、ブースは左側から始まって後方にホールを回りこむような感じで配置されてました。SUSE、Red Hat、Fedoraなどなど。

https://flic.kr/p/ntDesg
すぐ左はSUSE/openSUSEのブースでした。なんだかんだいって出典してるブースでは一番元気だったので、ヒマが会ったら出入りしていました。はっはっは。この写真の左に写ってるのがMax君、一度日本に来たときに私も一緒したので、「何だお前かよ！じゃあ今日のパーティ来いよ！」ってスピーカー＆スタッフディナーに誘ってくれた好青年です。

https://flic.kr/p/nL8XpB
ブースがあるホールはこんな雰囲気。

https://flic.kr/p/nL8XpB
systemdの基調講演をするLennart Poettering氏。

https://flic.kr/p/nKYomN
ライトニングトークで使ったドラ。GNOMEロゴがカワイイ。というかLTでドラを鳴らすのは日本文化というわけじゃないのねー。

さて私の写真にもどって。

LibreOfficeの発表をしたYifan Jiang氏との記念撮影。間にいるのは巨大Geeko。

巨大Geekoをアップで。隣においてあるコーラは500mlですからね！

ちびぎーこをぼくももらいました。この色のぎーこはまだ日本にはそんなにはないのかな？

スタッフ全員集合！の図。いやーみなさんお疲れ様！

初日が終わった後はみんなで学内の運動場に。私は最初誘われてバスケやったんだけどバスケなんて20年ぶりぐらいなので……あと脚が痛くてねぇ。ということで、卓球に移動しました。卓球も下手くそで相手してくれた方にはゴメンナサイという感じ。で、一緒にプレイしてた仲間と羊肉しゃぶしゃぶを食いに行きました。

美味かった〜しあわせ〜♪

なぜか皿と急須に燦然と輝くSeagateのロゴｗ

これ、我々がイベントやってた建物、新中央棟。すっげーデカイ。我々が使ってたのはその一部ではあるけど。すごいねー。

そんなわけで

遊んでくれた皆さんありがとう！

来年はどこでやるかわからないけど、行きやすいところでやってくれたらまた行ければいいな。
あと、LibreOfficeコミュニティとしてコラボできないか探りたいです。

いやー楽しかった！いってよかった！

*1:今の実装だとaufsではなくなっているらしいけれども。

2014-05-19

日経Linux 2014年6月号＆Software Design 2014年6月号

Book Ubuntu LibreOffice MongoDB

宣伝です。

久しぶりに雑誌に記事を書きました。あんまり商業誌にかけるような面白いネタ持ってないんですよねー。

日経 Linux (リナックス) 2014年 06月号

作者: 日経LINUX
出版社/メーカー: 日経BP社
発売日: 2014/05/08
メディア: 雑誌
この商品を含むブログ (1件) を見る

こっちにはMicrosoft OfficeからLibreOfficeの移行ネタを書きました。

編集さんからオファーをもらったときに「私が書くとしたらLibreOfficeはMS Officeの互換じゃないし、手間暇コストだってかかるという話を書きますけどそれでもいいですか？」って確認して、「あまりネガティブにならないようなら」ということで引き受けることにしました。

私が最初に書いた内容はもうちょっと「ん？移行？したければしたっていいんじゃない？別にしてほしいというつもりもないしさあ」みたいな感じだったんですが、ボリュームが少し足りなかったところもあって校正段階で加筆していただいて、正直自分ならそういう言い方はしないなあとは思ったけど考えが反してるわけでもないので、まあいいやと思って通しました。結果的にはまあまあバランスがとれた内容になったかと思います。

どっちかというと組織の中で云々というよりパーソナルに寄った記事が多い日経Linuxさんとしては、組織において移行をどう捉えるかということも含めて書かせていただいた私の記事はやや浮き気味だった気がしますが、個人としてなら「ん―好きなの使えばいいんじゃね？」以上にいうことはないので6ページのボリュームにはなりようがないので、ここは私の意見を通させてもらいました。好意的な反応もいただいたようでよかったです。

Software Design (ソフトウェアデザイン) 2014年 06月号 [雑誌]

出版社/メーカー: 技術評論社
発売日: 2014/05/17
メディア: 雑誌
この商品を含むブログ (4件) を見る

こっちについてはいくやさんの日記に先をこされてしまいましたが、Ubuntu Japanese Teamの皆さんが第二特集で手が回らないので、Monthly Report枠をなんでもいいから書いてくれってことで引き受けました。

といっても先ほど書いたとおり私って印刷とLibreOfficeと最近だとMongoDBぐらいしか持ちネタないし、4ページでナニかけばいいねんって思ってたんですが、知り合いがFacebookで「jqコマンド使うぐらいならmongoシェル使ったほうが便利だよ」っての書いてて、それだ！ってことで飛びつきました。

最初はMongoDBの説明はかっとばして他のドキュメント読んでねってことにして2ページで概要説明、残り2ページで実践編という感じで考えたんですが、やっぱCRUDぐらいはやらないとだめだよなあということで書いて出したら6.5ページぐらいになってさすがにだめじゃんということになりました。

最初の構想にしたがってCRUDの説明けずりまくったら、「さすがにこれではわかりにくいという意見が編集部内でも出たのであと2ページあげます」*1 といってもらえたので、MongoDBを全然知らない人でもちょっと便利に使えるかなあというレベルの説明はできたんじゃないかと思ってます。でも、書きすぎたのは事実なのでレイアウトがかなり厳しいです。いやー本当に申し訳ないです＞編集さん

気軽に使えるJavascriptコンソールという意味でもMongoDB意外と便利なので、みんなぜひ使おう！

*1:もちろん本当の説明はこんなぞんざいじゃないですよ。

2014-05-12

なぜぼくはAppleという会社が嫌いか

与太話

いつにもましてつまらないし、ちゃんと事実踏まえて書いてないから読まないでいいよ。

とあるイベント……と隠す意味はないな、Ubuntu 14.04リリースパーティ14.05にて「普通おしごとでUbuntu使うよね？」と題して、会社でWindows押し付けられてcygwinとかで辛い戦いするぐらいなら仮想マシンでUbuntu使うんだってアリだよね？という趣旨のプレゼンをしたです。

Using Ubuntu on your work / 普通おしごとでUbuntu使うよね？ from Naruhiko Ogasawara

で、質疑応答で「Macじゃなんでだめなの？」って聞かれたんで「私は宗教上の理由でAppleは嫌いだけど、もちろんWindows以外のマシンが選択可能ならありなんじゃないの？ OS Xはよくできてるし」って言ったらなんかそこ盛り上がっちゃってさあ。そこは本題じゃないんだけどなー。

それから今日のTwitterのTLで「ちゃんと理由があって避けているなら宗教上の理由とかいう表現はしないほうがいい」という発言をみかけた気がするので、じゃあ書いとくよ。と。でもつまんないしこんな説明毎回してたらかったるいので、今後とも私は「宗教上の理由でAppleにお金は落とさない」というでしょう。

なお私はAppleという会社が嫌いなのでApple製品であるところのMacとかOS XとかiOS搭載のiPhoneとかiPadとかは使いたくても使えません*1。ただ、ユーザーが使う商品としてはよくできてるなあと（人の評判を見て）感じることは多々あります（ソレに比べて我がAndroid端末は何度床に叩きつけたくなったかわからん）。そんなわけで全然使ってないので不正確な記述があったら嗤ってやってください。あい。

秘密主義

Appleという会社は秘密主義です。まあある程度どんな企業も秘密は持つものですが、リリースiOSスケジュールみたいなものを非公開にされると色々と弊害が。

極トリビアルなことをいうと、Unix系の印刷システムのコアにいるCUPSというモジュール、これは「新規リリースはOS Xのスケジュール合わせ」ということで決まっています。ので、OS Xがいつリリースされるのかわからなければ、CUPSのリリースがいつかもわかりません。

困ったことにCUPSはApple内部はSVNで管理されていて、リリースブランチごとにグローバルのgitにまとめられるスタイルでリリースされるので、βやRCというバージョンと最終リリースにどういう変化があるのかはリリースされてみないとわかりません。まあこれはCUPSのリリースマネジメントの問題といえばそうだけど、Appleって大体そうじゃない？　私の感触ですけど。

なお前職時代にもっと酷い（Appleの秘密主義のせいなのに悪者になるのはハードウェアベンダー）例も見てますが、これはもしかしたら機密保持的なナニカかもしれないのでやめときます。でも、ハードウェアベンダーの開発プロセスがわかる人なら、なんとなく思い至るでしょ？

閉じた綺麗な世界

iOSに顕著だけど、AppleのアンチDynabookには辟易する。結局彼らが作ってるものってメディアを消費するものであってパーソナル・ダイナミック・メディアではないんだよね。ってわかんない人はあらゆる年齢の「子供たち」のためのパーソナルコンピュータ読んでよ。

まあでも、OS Xはそうでもないんだよねえ。前身のNeXTからそうだといえばそうで、ジョブズっぽくない。不思議といえば不思議。

ソフトウェアはハードのおまけ

結局彼らのビジネスって、OSをどんどんアップグレードして古いOSと古いハードウェアどんどん切り捨てて新しいハードウェアを定期的に買い続けることができる人に向けてやってるようにしか見えない。それは悪いことではないよ、実際成功してるんだし。でもぼくはそういうのが露骨でイヤ。好きで使う人は自由だけど、私がイヤという自由はあるよね。

結局

食わず嫌いといえばそれまで。だけど、いいじゃん、私が使うか使わないか、好きか嫌いかの話をしてるのだから。で、毎回こんな説明してらんないから、「宗教上の理由」で勘弁してよ。

補遺（2014.5.13追記）

あくまでもパーソナルな感情を垂れ流しただけなのに意外と反響があってびっくりしてます。
一応補足しておくと：

この記事は「ぼくがなんでAppleという会社が嫌いなのかと聞かれたときの答え」を書き留めたのに過ぎないので、皆さんがApple社、あるいはその製品を好きだろうが好きじゃなかろうが使おうが使うまいが私は一切関心がありません。
この記事を読んでAppleを嫌いになってもらおうとかそういうことはゆめゆめ思っておりません。というか特に新味のある話は書いてないし。
私が所有したApple商品はiPodシリーズぐらいなので、商品の善し悪しはほとんど語る資格はないです。iPodシリーズはUbuntuと一緒に使うというシチュエーションでは大変腹立たしい経験をしましたが（楽曲のシンクロぐらい許してくれたっていいじゃんかケチ）、商品そのものは悪くないとは思います。
私はジョブズはそんな嫌いじゃないけどジョブズ信者はキモいと思っててウォズは大好きです。関係ないけどゲイツさんは悪く言われすぎな気がします。って、どうでもいいね。

*1:印刷オタクとしては後述の通りCUPS印刷システムのリファレンスとしてのOS XやiOSの機能は気になるのだけど、そこでお金を出してしまったら負けなので。