Welcome to The Document Foundation Planet

This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.

To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.


日曜日
2014年12月21日


face

この記事はLibreOffice Advent Calendar 2014の21日目です。遅刻しちゃってスミマセン。

昨日はHidemune Tanakaさんの「楽ちんな LibreOffice Extension の作り方」でした。

私は関東におけるLibreOfficeのふわっとしたつながりを作りたいと思って、関東LibreOfficeオフラインミーティングという定期イベントを立ち上げました。イベント資料なんかはGithubにリポジトリがあってそこで管理されているので、覗いてみてください。

今回は、関東LibOオフの紹介……は、上のサイトを見ていただくとして、どんな狙いというか、思いで立ち上げたかという話をごくカンタンにしたいと思います。

ざっくりまとめると:

  • 小笠原は「主宰」ではなく「発起人」
  • 目指すのは「みんな同列」な「サロン」
  • 出会える場所をある程度の頻度で提供したい

ってな感じですかね。


小笠原は「主宰」ではなく「発起人」

関東LibreOfficeオフラインミーティングは、関東にはそういえばLibreOffice関係で定期的に集まれるイベントってないなあ(関西は関西LibreOffice勉強会が昔からあった)、と思って、私がなんとなく始めたものです。

で、今のところ私が会場を手配したり、資料作って喋ったり、あれこれやっているので、私が幹事とか主宰っぽい感じになっててちょっと私不満なんですけどw。

関東のオフって、別に私じゃなくて、誰かが「こんなイベントやりたい」とか「こんな話をしたい」とかあったら、どんどん名前を使ってもらってもいいんですよ。例えば今は東京でばかりやってますが、例えば関東の他の県でやりたい!と思ったらやってもらっていいですし、私のトークはコミュニティコミュニティうるさいから、もっとエンドユーザーに対して使い方を教えるようなイベントがいい、って思ったらそう思う人がやってくださればいいのです。

そーゆー方がいたら、私とうぜん可能な限りお手伝いはしますので、名乗りを上げてくださいませ。


目指すのは「みんな同列」な「サロン」

関東オフはぜんぜん人が来ないイベントとして(私の中で)有名です。最低では二人ってことがありました。昨日やった19.1回に至っては、私以外誰も来ませんでした。企業さんなどから無償で会場をお借りするような場合、あまり人が来ないとかなり心苦しいので、ちょっと悩んだりもしなくはないです。しかしこれは確信的でもあります。

イベント集客についての記事とか読むと、必ずターゲティングについて書いてありますね。どういう人がそのイベントの対象なのか。その対象に対してどういうベネフィットを提供できるのか。それを明確に分かるようにしなさい。うんぬん。うんぬん。

……私は、そういう、「登壇者が聴衆に何かを与える」タイプのイベントをやりたくなかったんですね。というか、「登壇者」「聴衆」という垣根を作るのがイヤ。みんなLibreOfficeというものを媒介にした、一つのコミュニティ*1 の仲間であって、その仲間同士、知恵を交換しあったり手助けしあったり、単に一緒にお酒飲んで馬鹿話したり、そういう場所が欲しいというのがあった。

今日は時間が開いたから、ってふらっと寄って、あ、いつもの仲間がいるな、って場所を目指しているんです。ターゲティングしない。参加してくれた人たちに何を与えるかも、まったく定義しない。しいていえば、LibreOfficeというものを中心にしてコミュニティを作ることに関心がある人がターゲットで、コミュニティへの参加感が与えたいものかな。

……そりゃ、人来ないよね(^^; そもそも「集客」じゃないもの。お客様が欲しい訳じゃないから。仲間が欲しいから。

あ、繰り返しますけど、「一般のユーザーにコミュニティの参加感とかいってもダメでしょう」という方がいたら、そういうイベントをやるためのプラットフォームとして使っていただくのは、大変に歓迎です。ぜひお申し出を。


出会える場所をある程度の頻度で提供したい

さっきも書きましたが、「今日は時間が開いたから」ってふらっと寄れるためには、時間が開いたときにオフがやってなければいけません。なので関東オフは毎月開催が基本です。

東京というところはとにかく人が多いですが、IT系に限ってもイベントもまた多いところなので、「仕事帰りにふらっと寄れるイベント」を作りたいと思って、平日夜開催というのはわりとこだわってきました。

でも、週末の方が時間取れるなーとか、ガッツリ作業する日もあったほうがいいなーという方もいるかなということで、最近はHackFestという形の、週末の午前中集合でランチを挟んで夜までというイベントもやるようにしてきました……というのが今年の進展でしょうか。

あとセミナースタイルというのはどうしても登壇者と聴衆って感じになってしまう感があって、それからの脱却ということで、平日夜のもくもく会というのも最近はやってます。本当はワークショップとかもやりたいのですが、これは仕込みが大変だなあということで、実現できてない……ですね。

スタイルを固定化しないというのも人集めには不利なんでしょうけど、しょうがないですね、これは。


まとめ

関東オフは今年で2年ちょっとになるわけですが、月一、平日夜開催というスタイルから、いろんなスタイルを模索し始めたところが今年の展開です。割と色んなことができて、個人的には満足しています。

一方で、立ち上げたときから、それぞれのイベントを開催して、(大抵は)なんかしゃべって、ということを一人でやってしまったので、関東オフは私の色がかなり強く出たイベントに外部からは見えてしまっているのかなあというのは、わりと悩んでいます。といって、人に仕事をお願いするのがとっても苦手なので、ズルズルと来てしまってるというのが今年の反省。

来年こそは、自分カラーを薄めたいなあ、と思っているところです。

ま、ともかく、そんな感じでやっているので、興味がある方、時間があえば遊びに来てくださいね。



明日はKenichiro MATOHARAさんです。よろしくお願いします!

*1:コミュニティコミュニティうるさいですね、すみません。


月曜日
2014年12月08日


face

この記事はLibreOffice Advent Calendar 2014の9日目です。昨日はoshieさんの「Drawでかんたん! チラシ作り 」でした。

みなさん、LibreOfficeのバグハンティングセッションについてはご存知でしょうか。

リンク先から参照すると:

  • ダウンロード: http://ja.libreoffice.org/download/pre-releases/ (そこで「プレリリース版用のサーバーにアクセスし、必要なバージョンを入手する」をクリック)
  • テストしたいことをテスト
  • バグを見つけた? irc で報告 / バグ報告を書こう

たったこれだけ!です。


タイムベースリリースとバグハンティングの意義

LibreOfficeのリリースは、タイムベースというポリシーになっています。つまり、「ベータとかRCとか正式リリースとかのスケジュールが、予め決められている」というポリシーです(LibreOfficeのリリースプラン参照)*1。他のFLOSSだと、例えばUbuntuとかopenSUSEといったディストリビューション、GNOMEとかがタイムベースリリースですね。

タイムベースリリースの利点を雑駁にいうと:

  • 機能追加やバグ修正が定期的にリリースされることが保証されるため、進化が早い
  • ユーザーからのフィードバックが得られやすいので、変更に大胆になれる
  • コミュニティベースの作業のスケジュールが分かりやすい

といったことがあります。逆に見ようによっては欠点とされるものが:

  • QAプロセスをリリースマネージメントの中に入れ込むことが難しい

ということです。つまり、これこれの品質尺度を満たしたらリリース、といったマネージメントとはタイムベースリリースは馴染まないのです。

しかしこれは本当に欠点なのかというと、ものは考えようです。つまり、不具合があっても、それを発見することさえできればすぐに対応される可能性がある*2 のがタイムベースの強みです。したがってLibreOfficeにおける品質保証というのは、ユーザーが自らテストに参加し、不具合を発見して報告することを前提としているのです*3。品質保証チームは(もちろん自らテストもしますが、どちらかというと)報告された不具合を精査して開発者が分かりやすいように情報を付加したり、ユーザーがテストをするための基盤を整備したり、といった作業がメインとなっています。

おっと、脱線が過ぎました。バグハンティングセッションというのは、タイムベースリリースを採用しているLibreOfficeにおいて、リリース「前」になるべく多くのテストを行い、不具合を検出するということを目的としたバーチャルイベントです。エンドユーザーとしてはどうしても、自分でテストしてみるのはリリースされてから、ということになりがちですが、こういうイベントを設定することで、より多くの人に開発版を試してもらおう、ということです。

リリーススケジュールから一部を抜粋しました。

イベント
β1第47週, 2014年11月17日〜23日
RC1第51週, 12月15日〜12月21日
4.4.0リリース第5週, 2015年1月26日〜2月1日

前回のバグハンティングセッションはβ1のリリース直後、11月21日〜23日に設定されましたが、今回はRC1のリリース後なので、12月19日〜21日で予定されています。ここで多くのバグを洗い出すことができれば、4.4.0のリリースにはまだ一月近くあるので、(特に致命的なものは)間に合う可能性が高いと考えられます。


前回のバグハンティングセッション ミニレポート

前回は東京で11月20日九州(福岡)で11月21日の勉強会の一部を使って、それぞれバグハンティングをオフラインで行いました。また東京のHackFestにあたってはIRCチャネル(freenodeの#libreoffice-ja)を開けておいたので、リモートで参加いただける方もいました。

MozTrapベースでテストを行ったり、使い込んでいる機能のチェックをしたりと、いろんなテストをした結果、以下のバグを報告できました。

  • 報告したバグ: fdo #86552, #86553, #86557
  • 確認したバグ: fdo #86390
  • 見つかったけれどもまだ報告できてないバグ*4
    • Drawでフォントを非常に大きくして、マウスであちこちクリックすると文字が突如見えなくなる
    • WindowsのBaseで「レポート」→「デザイン形式でレポートを作成…」または「ウィザードを使用してレポートを作成…」を選ぶとハングアップする→β2でも直ってない模様。既知のバグか調べねば
    • Calcでマクロのパスワードロック機能が働かない(ロックできたように見えるが、ファイルを保存して再立ち上げするとロックが外れる)
    • 4.3以前の不具合で、Calcのパスワードロックを行うとマクロ内の文字列が化ける
    • Impressで、ファイルによって表示できない画像がある(例:関東LibreOfficeオフの過去の資料これβ2では直ってる?たぶんだけど

またオフラインセッション、やる?

もちろん各々が自分の手元でテストしてもよいのですが、オフラインでやることで、

  • バグ出しするぞ!というモチベーションが上がる
  • 見つかったバグを相互に確認できる
  • 違う環境での確認も素早く可能
  • 一人でもbibisectの環境を持っているとbibisectもできる

などなどとってもメリットがあったので、RC1合わせのバグハンティングセッションもオフラインでやろうかな?と考えてます。

興味がある方はご連絡ください!


明日はnogajunさんで、 「Writerの原稿からImpressスライドのひな型を作る」だそうです。よろしくお願いします!

*1:Apache OpenOfficeは、プロジェクトが定めた基準を達成するまでリリースしない戦略を取っています。

*2:当たり前ですが、不具合を見つけて報告したところで、それを直す開発者がいなければ不具合は直りません。しかし、発見されない不具合が黙って修正される可能性よりは、発見して報告されたものが修正される可能性は遥かに高いです。

*3:私がしばしば「エンドユーザーがコミュニティの一員であることを自覚し、積極性を持って関わるほうが、LibreOfficeについては幸せになれる可能性が高い」というのは、こういうことです。

*4:先日リリースされたβ2では再現するかどうか確認してません。バグレポートもチェックできてないので、どなたか確認してほしいです。


月曜日
2014年12月01日


face

こんにちは。この記事はLibreOffice Advent Calendar 2014の初日です。すっかり忘れてたなんてのは秘密ですが、公開遅くなりましてすみません。

さてさて、今回はちょっと今更感もありますが、LibreOffice Conference 2014 Bernの参加「裏」レポートです。裏というのは、表は日経IT Proさんに書かせてもらったからです。

カンファレンスの内容とかは色んな所でしゃべったりなんだりしたので(聞きたいという人は呼んでください ^^)、ここは裏レポートというだけあって、準備とかオフタイムとかなんとかそういう話。

お金とかそういう話

今回のカンファレンス会場はスイスのBern(日本だとベルンと表記されるけど、向こうの人はバーンって発音してたと記憶してます)。スイスといえば美しい自然、観光地として外国人を暖かく受け入れてくれる人柄、美味しいチョコレートと乳製品、などが浮かびますが、もうひとつ、とにかく物価が高い、って印象があります。航空券とかホテルとか高そうってイメージがありました。

では実際のところ、かかった費用ってどんなもんでしょ? 見てみましょう。あ、スイスフランで支払った分は、今のレートで計算してます(当時のレートなんか忘れた)。

費目金額備考
航空券\147,630タイ国際航空 成田 - バンコク - チューリッヒ 往復(エコノミー)
鉄道\7,800SBB チューリッヒ - ベルン 往復(二等車)
鉄道(追加)\6,000帰りのみ、一等にアップグレード
宿泊\34,6206泊(9/1〜9/6)、AirBnB(後述)
合計\196,050

意外と高くないでしょう? タイ国際航空サマサマという感じではあります。トランジットも2時間と、短すぎず長すぎずでしたし。ただ、これは季節にも依るんだろうなあ。観光ハイシーズンだと、もっと高いかもしれません。

あ、SBBの一等アップグレードですが、これは別に贅沢したくなったというわけじゃなくて、乗るとこ間違えて「お客様ここ一等ですよ」「え、そうすか?」「どうします、二等に移動もできますけど」「(あーもう疲れてるしな……)いいです、追加料金払います」ってなっただけです。間抜け。

それ以外の費用ですが。

まず、LibreOffice Conference自体は参加費無料です。これはそう決まってるわけじゃなくて、一昨年参加したベルリンのカンファレンスだと50ユーロ払った記憶がある。けど、まあはした金です。国際カンファレンスはけっこう払うもんだったりしますからね。

それでついてくるのが:

  • カンファレンスそれ自体
  • カンファレンス会期中(9/4〜6)およびコミュニティデー(9/3)の朝食および昼食、フリードリンク(コーヒー、水、ソーダ類)
  • 9/4のHack Nightおよび、9/5のSocial Event(フードとビール飲み食べ放題)

ですよ。イベント中はほとんどお財布からお金が出て行かない。スポンサー様様ですよね。

あと、個人行動分とかみんなでご飯食べにいった分とかは当然お金払ってますが、これは渡航前に3万円ぐらいをスイスフランに換金して持っていったので足りたんじゃなかったかな。おみやげはちょっとショートして、カードで支払った記憶がある。

そんなわけで、LibreOffice Conferenceは原則ヨーロッパでやるので高いな、って思うかもしれませんが、参加費とか滞在費はかなり安くなるので思ったほどではありませんよ、ということです。

AirBnB

AirBnBは最近露出も増えてますし、利用されたって経験がある方も多いかと思います。私は今回が初めてだったので面白いなと思いましたが、ここで仔細にレビューしなくてもよいでしょう。なによりプライバシーが欲しいって人には向いてないかもしれませんが、そうでなければ、リーズナブルな値段だけでなく、色々ふれあいのチャンスが得られて、でも自分の時間は確保できて、オススメです。

以下思い出話をちらほらと。

  • 最初に申し込むときにメッセージするの推奨って書いてあったので「今度オープンソースのイベントでそっち行くんだ。LibreOfficeって知ってる?」ってメッセージしたら「知ってるよ!オープンソースコミュニティで活動してる人を泊められるなんて光栄だよ」って返事が帰ってきて、蓋を開けてみたらホストは現地でDrupalによるWeb構築の会社をやってたという。日本だとDrupalどうよ?みたいな話をした。面白いね。
  • AirBnBのメッセージ機能はかなりよくできてて、現地ではSMSで送受信できるのでネット切れてても携帯あれば繋がって便利。
  • ホストは超親切で、「えーと部屋にはどうやって行けばいいの?」「あ、わかりにくいから迎えに行くよ、駅で合流しよう」ってわざわざベルン駅まで来てくれて、バス乗り場の位置から切符の買い方、バス停の位置まで全部教えてくれました。お部屋も清潔だったしオススメ。もしベルン行く人がいたら紹介します。
  • とはいえ部屋から会場までは徒歩30分ぐらいだったので毎日歩いて行ってました。朝6時半に起きてのんびり支度して7時に家出て、朝の冷たい空気の中を歩いて行くのは気持ちよかったです。帰りも歩いてたけど、毎日飲んだくれてて遅い時間だったから、道によっては結構暗くて怖かったw
  • お部屋は普通の何室かあるアパートの一室を貸し出す感じ。他の部屋はホストやその相棒が使っているそうです(ここは彼らのオフィスで、お家は別にあるので、毎日来るわけではないとのこと)。そういう意味でバストイレが共用なので、タイミングを見計らう必要はあります。
  • そしてぼくは同居人がシャワーを浴びてる最中にトイレに行きたくなり、ぴょんぴょん飛び跳ねる勢いで我慢したことがあります。トイレは行けるときに行っておきましょう。
  • 毎日遅く帰って早く出かける日々だったのでホストとゆっくり話す機会があんまりなかったのは少し残念。せっかくのAirBnBなので、そういう機会を作っても良いかもね。

観光とかとか

ベルンはあんまり大きな街ではないので半日ぐらいで一回りできます。とっても良い街なので、行ったらぜひ観光しましょう。カンファレンスのローカルチームが、イベント終了後の9/7(土)にツアーを企画してくれてたのですが、私は残念ながら土曜日の飛行機だったので参加できませんでした。もし可能なら、日程合わせて参加すると二倍楽しいと思うので、みなさんはぜひ。

そのかわり、月曜日の朝に着いたので月曜日はフラフラと一人で歩きました。でも月曜日だと博物館とか全部しまってて残念。写真とかは機会があったらいずれ。

面白かったのは、昼ご飯食べたあと一旦駅に戻ってきて、トイレ行こうと思って構内を歩いてたら、LibreOfficeのTシャツを着た人が前を通りかかって「あれっ」と思ったら、それがThe Document FoundationのFlorianAlexの二人だったというね。ベルリンで一回あったきりなので、声をかけたとき向こうはぼくのことわからなかったみたいだけど、ベルリンであったよね!って言ったら、ああお前か〜ようこそベルンへ、ってなって、ホテルまで遊びに行きました。で、その後みんなでご飯を食べに行くという展開に。全然観光じゃないな。


言葉とか

カンファレンスは公用語は英語ですが、多くはネイティブではないので安心です(なんだそりゃ)。まあ共通の土台はありますし、なんとかなりますよ。てきとう。そもそも、なんともならないと思う人は行かないと思うので。

今回はLTしましたが、その話はまた別途。あとQA roundtableでは「日本からはなんか意見ない?」って聞かれたりして適当に答えたりしました。ヨーロッパ人が多いLibreOfficeコミュニティにおいて、日本から来ている、というのはそれだけで価値なので、向こうは話を聞こう、理解しよう、というバイアスが結構かかっていて、その点は楽ではあります。

街歩きしたりご飯食べたりという点についてですが、ベルンはドイツ語圏なのでドイツ語ができたらそりゃいいに決まっています。けど、観光地なので大抵の人は英語しゃべれますので、その点は安心。同じアジアなのに、北京で絶望したときに比べれば格段の差です。


LTの話

というわけでやったわけです。LT。

これも、「せっかく行くのだからなんか喋ったりできないかな」ってついったで書いてたら、それを読んでたからだと思いますが我らがCalc HackerであるKohei Yoshidaさんが、Hack Nightのときにライトニングトークの取りまとめをしてたJan (Kendy) Holesovskyさんにつないでくれて、それで「じゃ、明日よろしくね!」ってことになったわけです。

資料はこちら:

最初自己紹介とかダラダラ書いてたら「君、5分しかないって分かってるかい?」ってKendyに怒られましてw、そりゃそうだと思ってガサガサ削ってこうなりました。でも向こうのLTってわりと1枚のスライドを丁寧にしゃべってスライド2〜3枚ってことが多いみたいで、Koheiさんによると「なんで彼はあんなにスライド急いでめくるの?」って聞かれてたそうですw

まあ実際のところ準備不足も甚だしいし、練習なんかまったくしてないからスライドとにらめっこで聴衆の方見る余裕ないし、いろいろ酷くて、すっごい落ち込んで、あーだめだ、もうつらい、って頭抱えてたら、「さっきの話、面白かったよ」「続き聞かせてよ」って席まで来てくれる人がいて。はー。うれしいですね。

ここで満足して英語の勉強しないので上達しないんですが(こら)、でも、概ね受け手は優しい。これは主張しておきたいです。はい。


まとまってないまとめ

多分LibreOffice Conferenceはしばらくはヨーロッパを巡回することになると思います。この点はお酒飲みながらでも話題になったのですけど、やっぱりコミュニティの強さとか色々考えると、TDF(ドイツ)やLibreItalia(イタリア)、それからCollabora(イギリス)があるヨーロッパ*1 の強さは光りますわね。サポートベンダーの層も暑いし。

で、ダイバーシティは、TDFからの旅費補助によるカンファレンスへのローカルメンバーの誘致とか、あと地域カンファレンスに中核メンバーが参加するなどといったことで確保するほうがいいんじゃないか、という。

これは地理的・参加者の旅費補助費用とかの問題だけじゃなくて、例えば日本でLibreOffice Conferenceを開催したとして、日本のエンドユーザーが英語トラックを聞きに来るか、それを聞いて満足するか、それが日本コミュニティを盛り上げることにつながるのか、ということを考えると、まあそうだよね、という。我々はコンシューマプロダクトを扱うコミュニティなので、コンシューマにとって国際カンファレンスをやることが意味があるか、というのは考えなければいけないですね。

でも日本からの情報発信というのはとても期待されていて、とくに事例を発表できる人、旅費補助はするからぜひ来て欲しい、と色んな人にいわれました。来年はデンマークです。ぜひ皆さん、ご検討ください。

さて、初日終わり。明日は榎さんです。よろしくお願いします。

*1:イギリスはヨーロッパじゃない、とかいう話はおいといて。


日曜日
2014年11月02日


face

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について、を確認。

f:id:naruoga:20141102094904p:image

大丈夫そうですね。


コードの修正

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

豆知識としては、LibreOfficeはビルド時に依存するライブラリのバージョンを固定するために、サーバーにおいてあるtar ballを落としてきてworkdir/UnpackedTarballというところに展開します。その他yaccの生成物とかもあるので、単にgrep -r するとそういうのがいっぱい引っかかってしまうので、git grep使うほうが100倍ぐらい賢いです。

ということで、git grep OSL_ したら、あるわあるわ。どれ直してももちろんよいのですが、一部のソースは特定のconfigureオプションをオンにしないとコンパイルされない(そして、そのconfigureオプションはほとんど誰も使っていない)とかある*4 ので、ちょっとだけ注意が必要です。今回は pyuno/source/module/pyuno.cxx というソースを直すことにしました。変更が2行しかないのでw

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

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


木曜日
2014年08月28日


face

小ネタ。

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

でもなんか、ある日突然、時間単位課金が可能になってるじゃないですか。超びっくり。これは試すしかない!

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

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

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

とりあえず /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 

日曜日
2014年06月08日


face

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

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

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


最初にお礼

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

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

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

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


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

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

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

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


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

にも一部(連載第1回だけかな?)再録されているので、お手元にある方はぜひ。


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


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


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

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

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

(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日


face

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

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

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


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

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

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

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

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

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


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

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

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


'CD' using Docker - Gerard Braad

このトークは面白かった……話術がw

彼はThoughtWorksのコンサル(今?元?)だそうで、弁が立つのも当然といえば当然か。質問したら:

この本もらったよ。

ふむなるほど、って思ったのは、「普通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を使わなくていいのがいいよね!だって。w

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


ちょっと青年の主張とか

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

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

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

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


その他小ネタ

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

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

あと写真を少々。

f:id:naruoga:20140523131149j:image:w360

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

f:id:naruoga:20140523142922j:image:w360

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

f:id:naruoga:20140523141958j:image:w360

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

f:id:naruoga:20140523144429j:image:w360

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

f:id:naruoga:20140523160721j:image:w360

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

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

f:id:naruoga:20140531201126j:image:w360

https://flic.kr/p/ntDnh3

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

f:id:naruoga:20140531201127j:image:w360

https://flic.kr/p/ntDesg

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

f:id:naruoga:20140531201128j:image:w360

https://flic.kr/p/nL8XpB

ブースがあるホールはこんな雰囲気。

f:id:naruoga:20140531210144j:image:w360

https://flic.kr/p/nL8XpB

systemdの基調講演をするLennart Poettering氏。

f:id:naruoga:20140531210145j:image:w360

https://flic.kr/p/nKYomN

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

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

f:id:naruoga:20140525103125j:image:w360

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

f:id:naruoga:20140524123736j:image:w360

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

f:id:naruoga:20140525142223j:image:w360

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

f:id:naruoga:20140524180533j:image:w360

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

f:id:naruoga:20140524185943j:image:w360

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

f:id:naruoga:20140524203511j:image:w360

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

f:id:naruoga:20140524202855j:image:w360

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

f:id:naruoga:20140525134107j:image:w360

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


そんなわけで

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

来年はどこでやるかわからないけど、行きやすいところでやってくれたらまた行ければいいな。

あと、LibreOfficeコミュニティとしてコラボできないか探りたいです。

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

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


月曜日
2014年05月19日


face

宣伝です。

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

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

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

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

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

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

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


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

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

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

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

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

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


水曜日
2013年12月25日


face

みなさん、メリークリスマス*1 です :)

さてさて、Doc-ja Advent Calendarもいよいよ最終日となりました。なかなか読みでがある記事が多くて楽しかったですね。

そんな最後に、今回もまたちょっとしたネタを書こうと思います。


二つの「ローカライズ」〜ローカル言語化と地域向けコンテンツ〜

LibreOfficeにはWikiがあります。URLがちょっとわかりにくいのですが http://wiki.documentfoundation.org をトップページとするものです(我々はよくTDF Wikiと読んでます)。ここのコンテンツは基本的に英語で、例えばマーケティングのページならURLは https://wiki.documentfoundation.org/Marketing で、後ろに/jaをつけた https://wiki.documentfoundation.org/Marketing/ja は「日本語版」なわけです。

だけど、「グローバルな情報を日本語に翻訳した」情報が、「日本語話者が主に日本で利用するために欲しい」情報とイコールではないですよね。そういう理由で LibreOffice Wiki には http://wiki.documentfoundation.org/JA (通称 JA) というカテゴリーがあって、これはまさしく、日本語話者が主に日本で利用するための情報を書いているわけです。


欲しいのは日本語訳? それとも日本での情報?

LibreOfficeはいつもリソース不足に悩んでいます*2。したがって、Wikiを書いたり更新したりするときに、常に考えるわけです。「この情報はグローバルから翻訳したほうがいいのか、それとも日本語独自コンテンツにしたほうがいいのか」と。

例えばLibreOfficeの日本語UI/ヘルプの翻訳方法は、日本語チームが定めて日本語のMLで議論した日本語翻訳独自のルールその他が書いてあるページなので、ここは翻訳ではなく独自コンテンツにするべきだと(少なくとも)私は考えました。その点については合意は得られていると思います(ちょっとまだ書き足りていませんが)。

一方で翻訳プラットフォームであるPootleの使い方は世界中で共通です*3。なので、Pootleガイドについてはオリジナルコンテンツではなく、日本語訳を用意しているわけです。

ここのところの判断はいつも悩んでいるので、もしグローバルのWikiを見て「翻訳欲しいなあ」と思われた方は、ぜひぜひその旨を知らせてもらえればなと思います。逆に「細かい話は英語で読むから、入門的な話とかを独自に書いて欲しい」という意見も歓迎です。もちろん、TDF Wikiはサインアップすれば誰でもページ作成可能なので、ご自分でページ作ってもらっても構いませんよ*4

個人的には Development 関係は「どうせ深入りしたい人は英語と向き合わざるを得ない」ので翻訳よりかはエントリー層向けのガイドラインを独自コンテンツで書き、エンドユーザーや非開発系(翻訳も含む)向けコンテンツは翻訳でやるのがいいのかなあと考えています。


日本リージョナルな情報を英語で発信

私が最近ちょっとやってるのは、「日本だと誰がどんなことやってるの?」ということをグローバルに対して発信したいということです。アクティビティを見せることはFLOSSにおいてとても重要だと私は考えているので。なので下手くそな英語でブログ書いたりしてるわけでして*5

で、同じようなことをTDF Wikiでやるのが密かに辛いのですな。というのは、先ほど書いたように「末尾に /ja がつく翻訳コンテンツ」と「頭に JA/ がつく日本語独自コンテンツ」があるけど、日本リージョナルな情報を英語で書く「ここ!」という場所がない。「日本のイベント情報」を書こうとしてはたと困って、しょうが無いので https://wiki.documentfoundation.org/Events/Japan こうやって無理やり書いたんですけど……。なんかいい方法ないかなあ?


おわりに

ドキュメントワークも重要な翻訳でございます。でも翻訳が必ずしも優先度が高いわけでなく日本語話者、日本向けの独自コンテンツのほうが大事なときもあるわけで。翻訳は情報提供の手段に過ぎないので、グローバル文書の翻訳カバレッジを上げることが目的化しないようにしたほうがいいですね。

では! 年末も残り少ないので、良いお年を!

*1:一瞬素で「あけましておめでとう」と書きそうになりました。おいおい……。

*2:LibreOfficeに限らず、たいていのFLOSSはリソース不足が常態化しているでしょう。

*3:権限周りで、どの権限を誰が持っているかというのは翻訳チームごとに違いますけれども。

*4:WikiエンジンとしてはWikipediaと同じMediaWikiを使ってます。Wikipediaよりはバージョンは古いかも。一応、LibreOffice WriterからMediaWiki記法へのエクスポートは可能です。

*5:URLはヒミツ。といっても、検索すればすぐ出てくるのですが。


土曜日
2013年12月14日


face

このエントリーはLibreOffice Advent Calendarの14日目です。公開遅くなっちゃった。

で、いろいろバタバタしていたらネタを仕込む暇がなかったので今日は軽めなエントリー。榎さんのエントリーも併せて読んでね。

LibreOfficeのようなFLOSS*1 についてはオンライン上でのやりとりが中心になることが多いです。LibreOfficeの場合、日本語のやりとりが最も活発なのはメーリングリストですが、それ以外には情報発信用のTwitterアカウントや、Facebookページなどもあります。準公式という位置づけでフォーラムもあるんですがこっちは私あんまり見に行ってないので……ごめんなさい。なお公式のフォーラムが近々準備される予定です。

ということなんですが、人間というのは不思議なもので、オンラインでなかなか出てこないことであっても、顔を合わせてダラダラしゃべってると結構「あ、なんだそんな手あるんだ」とか「あれ、普通に使ってるこの機能、みんな知らないんだ」とか「こないだからちょっとおかしいなぁと思ってたこの問題、みんな困ってたんだ。バグで起票しなきゃ」とかあるわけです。そういう意味で、絶対オフラインの交流は必要。というのは、榎さんのエントリーにあるわけですが。

で、関西は何ヶ月に一度か、週末にがっちり時間を取ってセミナースタイルで「関西LibreOffice勉強会」というのを榎さんがやっているわけですが、関東は人がたくさんいて勉強会とかその他のITイベントたくさんあるから、もっとカジュアルなイベントが欲しかったわけです。「とりあえず顔合わせるチャンスを増やそう」っていう。

そんな動機でやっているのが関東LibreOfficeオフラインミーティングです。

月一、平日の夜開催なのは「仕事帰りにふらりと寄れる」を目指しているからだし、セミナースタイルにこだわらず、ワークショップとかもくもく会とか読書会とか単なる飲み会とかいろいろダイバースしていけばいいな―と思っております。イベントの募集はconnpassでやってるので良かったらウォッチしてくださいませ。


宣伝!

とはいえ平日の夜だと会場*2 が職場の動線上にないと却って参加しづらい、週末のイベントのほうがいい、という人もいるのかなって考えました。

そんなわけで12月21日という暮れも押し迫った時期*3 ですが、関東LibreOfficeハッカソンというイベントをやることにしました。ハッカソンというのは hack-a-thon ということでハック (プログラムをいじったり何だりすること) とマラソンをかけた言葉ですけど、そんなに固く考えずに:

  • LibreOfficeをハックしたり
  • LibreOfficeの翻訳をやったり
  • LibreOfficeのバグを調べたり
  • 単にもくもく使ったり
  • LibreOfficeでマクロやLibreLogoのプログラミングで遊んだり
  • LibreOfficeのユーザーに会いに来たり

していただいて結構です。3時にはおやつタイムでコーヒーとケーキを楽しんだりしますし、19時半からはピザとビールで乾杯と考えてます。気軽に来てね!

なお、大体3ヶ月か4ヶ月に一度(いまんとこ一人で回してるので、私の手が回る範囲で、ともいう)、今回ほどではないにせよ、関西の勉強会のような週末型のイベントをやろうとは思っています。どんなものになるかは全然考えてないので、意見くれると(もっというと手伝ってくれると)イベントの内容をコントロールできる可能性が高いです。


野望!

  • 関東でやるかどうかはまだわかりませんが、来年の前半に終日のLibreOfficeイベント全国版をやりたいですね。今年のLibreOffice Japan mini Conference 2013みたいな奴。手伝ってくれる人大募集ですよ。エンドユーザーの皆さんにも面白いと思ってもらえるイベントにしたいです。
  • そして、その次の年ぐらいにできたらいいなあ、東アジア(日中台韓)のインターナショナルカンファレンスをやりたいです。まあ、これは、やりたいって私が一人でいってるだけなんで、実現性はまだわかりません。でもアジア圏はもっと交流したほうがいいと思うんだ。

まあなんにせよ、関東のオフは「出会い系」なので、気が向いたらふらりと来てね。来てくれるのが一番うれしいです。

手伝ってくれる人がいたらもっと嬉しいけど、まあ、それはぼちぼちと、ね。

*1:Free / Libre Open Source Software の略。自由でソースコードが公開されたソフトウェアのこと。

*2:今は麹町のKDDI ウェブコミュニケーションズさまに会場をお借りすることが多いです。

*3:クリスマス前の三連休初日で空気読んでないともいう……。

過去のブログエントリー ->