転職します
以上。終わり。
……でもいいですが、もうちょっと追記。
3月31日付けでミライト情報システムを出て、4月1日から新しい仕事につきます。
入社のときのエントリーを見ると色々気恥ずかしいですね。3年に満たない期間で離れてしまったのは、まあ、勤まらなかった、といえばそうです。これに関してはなにを書いても言い訳っぽくなるのでやめます。
前職はいわゆる揶揄されることの多い中堅どころの「えすあいやー」であって、そういうところにはITを専門に学んできてない人がいっぱいいて、仕事にも技術にも興味なんかぜんぜんなくて、でもデスマって消耗してるって、ついったとか見てるとそんな感じですよね。
でもそんなことなくて、技術や業務知識について学習意欲もあるし実力もある特に若い層が結構いて、あるいは育っていて、中堅どころもそれぞれに持ち味もあって、上は面白いことに関心があったり本人が面白かったり（ぉ、すごくいい職場でした。一緒に働くことができて幸せでした。えすあいやーを十把一絡げに悪くいわないで欲しいなあ、と思ったりしました。
ぼくの立ち位置は社内R&Dというか、自分のチームでやってることの先行技術探索とか、そのためのちょっとしたプロトタイピングとかで、それはとても面白い仕事でよかったんだけど、そんなにお金儲かってない中でなんでぼくがそんな仕事させてもらえたかっていうと、それは単純にぼくが体調を崩してしまったので納期がタイトな仕事をやれなかったという点もあって、ね。フクザツではあります。
知ってる人は知ってますがぼくがMongoDBと関わったのはこれをビジネスにしようという動きがあったからです。今の会社辞めるので仕事的には縁が切れます。けど、MongoDBは好きだしMongoDBを通じて知り合った人たちともこれからも仲良くなんかできたらいいなとは思ってます。
転職……ということなので、次の仕事は決まってます。というか明日初出社なので日記なんか書いてないで寝ないといけません。
普段のぼくなら社名をじゃじゃーんと書きたいのですが、正直、まだ自分に自信が持てないというのがあります。健康不安を抱えつつ、ほんとうに新しい会社にコミットできるのかどうか。なので、自信が持てるまでは、隠すわけではないけど、大々的に書くのは控えようかなと。
ただ、新しい会社でやっていることが本当に面白そうで興味を持てて、こういうことをやっていれば健康面でもプラスになるんじゃないか、って思ったのはそうです。それと、健康面にも不安があるということを伝えてなおかつ一緒に仕事をしたい、という、とてもありがたい言葉をもらいました。ですから、自分と周りと相談しつつ、今の（残念ながら）悪いループから抜けだすチャンスだと思っているので、そうなったって自分に自信を持てるようになったら、もっと堂々と「こういう会社でこういう活動をやってます！」っていおうと思います。いえるようになるべく、ぼちぼちやりますね。
それと、各種コミュニティ活動についてはむしろ推奨という感じに受け取っているので、そっちのほうから自然に名前が出るかもしれません。というか、出るといいですね。
そんなわけで、とりとめもありませんがよろしくお願いします。ぺこり。
デザパタを一人でこっそり振り返ろう #5 (Singleton)
なんと前の記事を確認したら3年近く前だよ…… orz
この連載？は、へっぽこプログラマー（厳密には足を洗ったので「元」）のぼくがひょんなきっかけから、Javaプログラマー向けデザインパターンの入門書として有名な：
- 作者: 結城浩
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2004/06/19
- メディア: 大型本
- 購入: 51人 クリック: 762回
- この商品を含むブログ (400件) を見る
（以下 JDP）を買ったはいいけどなんかやる気なくて放置してたところに、これまた Smalltalk 界隈の人に教えてもらった：
Design Patterns Smalltalk Companion, The (Software Patterns Series)
- 作者: Sherman Brown, Kyle Woolf, Bobby Alpert
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 1998/02/10
- メディア: ペーパーバック
- 購入: 1人 クリック: 23回
- この商品を含むブログ (9件) を見る
（以下DPSC）を買って読んだらむちゃくちゃ面白くて、じゃあ JDP の内容を Smalltalk で実装したあと、DPSC を答え合わせ的に読む、ということをやったら自分の勉強になるし、「動的言語におけるデザインパターンは静的言語のそれと違う」って意味が噛み締められるんじゃないかと思って始めたものです。
過去の記事は次のとおり。
- デザパタを一人でこっそり振り返ろう #1 (Iterator)
- デザパタを一人でこっそり振り返ろう #2 (Adapter)
- デザパタを一人でこっそり振り返ろう #3 (Template Method)
- デザパタを一人でこっそり振り返ろう #4 (Factory Method)
ということで今回は Singleton パターン。言わずもがなではありますが、JDP から引用すると(p.58)、
指定したクラスのインスタンスが絶対に1個しかないことを保証したい
というものですな。これまた同じページから引用すると：
現在のシステム設定を表現したクラス、ウィンドウシステムを表現したいクラスなどが代表的な例
だそうです。ウィンドウシステムって、どのウィンドウもどっかからちゃんと手繰れないといけないんだけど（でないと、例えばマウスクリックとかのイベントを誰に渡せばいいんだかわかんなくなる）、そういうときに「全部のウィンドウの根っこ」とか持ちたくなるわけですね。そういうのをシングルトンで管理するよと。
そんなにインスタンスの作成を抑制したいんだったら、全部クラスメソッドでさばいてインスタンス作んなければいいんじゃね？と思うんですが、まあよくわかんないので教科書を追います。
ひとまず実装
JDP の例を見てみましょう。シングルトンであるクラス Singleton を作ります。
平たく言ってしまえば new を禁止して、代わりに「まだインスタンスがなければ new したものを、そうでなければすでにあるインスタンスを返す」メソッド getInstance を提供するってな感じです。Java の場合は new を禁止するにはコンストラクタ Singleton を private にすればいいわけですが、さて Smalltalk だとどうするか。private なんて Smalltalk にはねーよ。
まあ new 禁止を考えずにクラスの定義をば。
super new については前回 #4 で説明したとおり。ここで Singleton new ってやっちゃうと怒られる。……いや、これ self basicNew のほうがいいね。あとで気づいた。
でも自身の new 潰してないんだよなあ。ということで new にカーソル当てて alt-M でインプリメンタ出してなんかいいのないかなーと見てると、お、こんなんあった。
Bool class>>new self error: 'You may not create any more Booleans - this is two-valued logic'
ふむ。self に error: で適切なエラーメッセージを投げてやればいいのね。じゃあこんなん？
そうすると「new 潰すと酷いことになるかも知んないけどマジいいの？」って聞かれるけどまあ構わずセーブ。
さてとワークスペース開けて試してみましょう。
a := Singleton getInstance.
b := Singleton getInstance.
a == b[print it]→true
ほい。うまくいったっぽい。
DPSC の解説
さて答え合わせ答え合わせ。DPSC の Singleton パターンは 91 ページから。ふむ。大筋は合ってるっぽい。new は self>>error: で潰せというのも正解でした。
Smalltalk 的にはシングルトンそのもの、あるいはシングルトンっぽいものはたくさん使われてるよって書いてあります。例えば Squeak の場合は Smalltalk 変数というのがいてコイツがグローバルな色々な何かを持ってたりしますが、このクラスである SmalltalkImage というクラスは new は「Smalltalk 使えよ」ってエラーを出すように潰してあります。
ということで、大抵のシングルトンパターンの場合は、システムそれ自体のグローバル変数とかに持っててそれ経由のアクセスをするのが普通なわけです。例えば上の例で示した Smalltalk 変数とかね。で、コイツの初期化はシステムのブートアップにやりますよと。でもシングルトンのオブジェクトってそれこそシステム根幹の情報なわけで、それをグローバル変数に持つってのはどうなのよ？ 危なそうに見えるよね？ と。
で、答えとしては、グローバル変数じゃなくてシングルトンオブジェクトのクラスに一つのメッセージを用意して、そいつからインスタンス変数にルーティングすればいいじゃんって。オブジェクトが生成されたとき、初期化されたとき、GCによって破棄された時など、クラスなら適切に扱えるじゃんねーと。なるほどね。でも実際のところ Smalltalk の大抵のシングルトンオブジェクトはグローバル変数で管理されてますよと。なんでやねん。
ちょっと英語苦手なんで実は意味読み取れてないんだけど引用：
Design Patterns states that Singletons accessed through global variables are not really example of the Singleton pettern (DP 127). One might argue that other examples are Singletons and they're just not implemented optimally.
デザインパターンではグローバル変数経由でアクセスされるシングルトンを Singleton パターン (DP 127) の実際の例とはしていません。一つ考えられることは、他の例はシングルトンなのですが、最適な実装がされていなかったということです。
つまるところ GoF ではシングルトンオブジェクトをグローバル変数に突っ込むのを「パターン」ではないとしてるけど、それっぽい例があるから「おーこうやって実装するといいねー」って最初実装しちゃったって話？ そうなんかな。まあいいや。あ、ここで DP 127 っていうのはいわゆる Gang of Four (GoF) のデザインパターン：
![オブジェクト指向における再利用のためのデザインパターン改訂版 [ エリック・ガンマ ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/7973/79731112.jpg?_ex=128x128 "オブジェクト指向における再利用のためのデザインパターン改訂版 [ エリック・ガンマ ]")
のページ 127 にあるパターンって意味です。はい。
とにかく本当はグローバル変数に突っ込むのは良いやり方ではないけど、Smalltalk ではそういう例がいっぱいあるってことはわかった。
シングルトンのバリエーション
シングルトンには persistent (永続)、transient (一時的)、single-active-instance (単独アクティブインスタンス) の三つのバリエーションがあるとのこと。
- 永続シングルトン - 特定のクラスの唯一のインスタンスであり、なおかつ永遠に変わらないもの。
- 一時的シングルトン - あるクラスの唯一のインスタンスだけども、インスタンスは変わりうるもの。例えばセッション情報を管理するオブジェクトはシングルトンであるが、セッションが破棄されると破棄され、新規にセッションが起きると再生成される。
- 単独アクティブインスタンス - あるクラスに対し、アクティブまたは有効であるインスタンスは一つだけだが、インスタンス自体は複数存在するもの。例えば IDE のプロジェクトを管理するクラスがあるとして、IDE は複数のプロジェクトをオープンできるのでインスタンスは複数存在するけど、実際にプログラマーが弄ってるプロジェクトに対応するプロジェクトだけが有効とかそういう。実際にはシングルトンではないけど、性質的には似てるから一緒に論じますよと。
Smalltalk における実装について
Smalltalk 内部で実際に使ってるケースを紹介してくれるところが DPSC のうれしいところ。
GoF では Singleton パターンの要件として「(A)あるクラスがただひとつのインスタンスしか持たないこと」だけでなく、「(B)グローバルにアクセスできる方法を提供すること」を挙げているらしいです。ん？ JDPにはその要件はスルーされていたような……。まあいいや。
単一インスタンスの保証
で、(A)はさっき議論したように、Smalltalkの場合はクラス変数 (Java の場合は静的メンバー変数っていうのかな）に作ったインスタンス放り込んでおいて new 禁止ってやり方でいいよねと。で、ついでにこんなふうな実装もありうるねと。これは Visual Smalltalk の UndefinedObject クラス。
UndefinedObject>>new "レシーバーの新たなインスタンスを作る。このクラスでは単一のインスタンス nil が 存在するため許可されない。" ^self invalidMessage
で、invalidMessage を別途定義することで再利用性を上げると。ただ、VisualWorks とか Squeak とかこういうふうにしてなくて素朴に self>>error: 投げてる処理系も多いよと。
C++とかJavaの場合はnewをプライベートにするだけでできることなんだけど、すでにあるクラスを隠すって概念がないSmalltalkの場合は実行時例外を上げるしか方法がなく、文法レベルでチェックができないのは欠点だよねってことが書いてありました。まあそれは一理あるわなー。
インスタンスへのアクセスの提供
(B) についてですけど、さっきも書いたとおりグローバル変数を使うやり方は乱暴ではあるけど一応機能はする。もっと良いやり方はクラスでプロキシーする方法で、getInstance って名前はいかにも「インスタンスを貰う（貰った側が代入して持つ）」って名前でこれはちょっとよろしくない。ので、名前をcurrentとかに変えれば：
Singleton current someMessage.
みたいに自然に書けるでしょ？ というお話でした。
new を潰さない方法ってどう？
よくよく考えてみると、newを潰す必要は別になくて、単にこうすればいいんじゃないかと。
Singleton class>>new ^self current
上の議論により self current はシングルトンオブジェクトを（必要なら内部で new して）返すんだから、これによって常に new で同じものが帰るよねと。
問題は、new って名前が「いかにもインスタンスを生成しそう」って名前なので：
| roadRunner wileECoyote | roadRunner := SingleToon new. wileECoyote := SingleToon new. roadRunner position: 100@100. wileECoyote position: 200@200.
で、実は roadRunner と wileECoyote が同じオブジェクトだとはお釈迦様でも気づくめえってことですわね。ので、やっぱ new は潰しておくほうが無難かなと。プログラマーが混乱したんじゃ意味ないんで。
クラス階層の中でのシングルトン
「このクラスのサブクラスの中のインスタンスは一個しかあっちゃダメ」みたいなことが欲しいときはどうするかって話ですね。Smalltalk の場合は一瞬で、クラス変数の代わりにクラスインスタンス変数を使えばいいですよと。つまり：
Object subclass: #Singleton instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'DPStudy-Singleton' Singleton class instanceVariableNames 'Singleton'
とやれば後は同じでいいですね。っていうかクラスインスタンス変数ってこんなふうに使うんだー。
おっと、単なるテキストの引き写しになってる。いかんいかん。
その後も DPSC は「アクセサの名前 current とか default とかってどう決める？」とか、ぼくが最初に書いた「全部クラスメソッドでよくね？」とかそういう話があって、もっと具体的なコード例（データベースのラッパークラス）とかSmalltalkクラスライブラリの中での使用例とかいろいろ書いてあるわけでこれもまためちゃくちゃ面白い。が省略。買って読んで。
さて次回はいつになるかわかりませんがPrototypeパターンだそうです。お楽しみに。
関東LibreOfficeオフラインミーティングとはなにか
この記事はLibreOffice Advent Calendar 2014の21日目です。遅刻しちゃってスミマセン。
昨日はHidemune Tanakaさんの「楽ちんな LibreOffice Extension の作り方」でした。
私は関東におけるLibreOfficeのふわっとしたつながりを作りたいと思って、関東LibreOfficeオフラインミーティングという定期イベントを立ち上げました。イベント資料なんかはGithubにリポジトリがあってそこで管理されているので、覗いてみてください。
今回は、関東LibOオフの紹介……は、上のサイトを見ていただくとして、どんな狙いというか、思いで立ち上げたかという話をごくカンタンにしたいと思います。
ざっくりまとめると：
- 小笠原は「主宰」ではなく「発起人」
- 目指すのは「みんな同列」な「サロン」
- 出会える場所をある程度の頻度で提供したい
ってな感じですかね。
小笠原は「主宰」ではなく「発起人」
関東LibreOfficeオフラインミーティングは、関東にはそういえばLibreOffice関係で定期的に集まれるイベントってないなあ（関西は関西LibreOffice勉強会が昔からあった）、と思って、私がなんとなく始めたものです。
で、今のところ私が会場を手配したり、資料作って喋ったり、あれこれやっているので、私が幹事とか主宰っぽい感じになっててちょっと私不満なんですけどｗ。
関東のオフって、別に私じゃなくて、誰かが「こんなイベントやりたい」とか「こんな話をしたい」とかあったら、どんどん名前を使ってもらってもいいんですよ。例えば今は東京でばかりやってますが、例えば関東の他の県でやりたい！と思ったらやってもらっていいですし、私のトークはコミュニティコミュニティうるさいから、もっとエンドユーザーに対して使い方を教えるようなイベントがいい、って思ったらそう思う人がやってくださればいいのです。
そーゆー方がいたら、私とうぜん可能な限りお手伝いはしますので、名乗りを上げてくださいませ。
目指すのは「みんな同列」な「サロン」
関東オフはぜんぜん人が来ないイベントとして（私の中で）有名です。最低では二人ってことがありました。昨日やった19.1回に至っては、私以外誰も来ませんでした。企業さんなどから無償で会場をお借りするような場合、あまり人が来ないとかなり心苦しいので、ちょっと悩んだりもしなくはないです。しかしこれは確信的でもあります。
イベント集客についての記事とか読むと、必ずターゲティングについて書いてありますね。どういう人がそのイベントの対象なのか。その対象に対してどういうベネフィットを提供できるのか。それを明確に分かるようにしなさい。うんぬん。うんぬん。
……私は、そういう、「登壇者が聴衆に何かを与える」タイプのイベントをやりたくなかったんですね。というか、「登壇者」「聴衆」という垣根を作るのがイヤ。みんなLibreOfficeというものを媒介にした、一つのコミュニティ*1 の仲間であって、その仲間同士、知恵を交換しあったり手助けしあったり、単に一緒にお酒飲んで馬鹿話したり、そういう場所が欲しいというのがあった。
今日は時間が開いたから、ってふらっと寄って、あ、いつもの仲間がいるな、って場所を目指しているんです。ターゲティングしない。参加してくれた人たちに何を与えるかも、まったく定義しない。しいていえば、LibreOfficeというものを中心にしてコミュニティを作ることに関心がある人がターゲットで、コミュニティへの参加感が与えたいものかな。
……そりゃ、人来ないよね(^^; そもそも「集客」じゃないもの。お客様が欲しい訳じゃないから。仲間が欲しいから。
あ、繰り返しますけど、「一般のユーザーにコミュニティの参加感とかいってもダメでしょう」という方がいたら、そういうイベントをやるためのプラットフォームとして使っていただくのは、大変に歓迎です。ぜひお申し出を。
出会える場所をある程度の頻度で提供したい
さっきも書きましたが、「今日は時間が開いたから」ってふらっと寄れるためには、時間が開いたときにオフがやってなければいけません。なので関東オフは毎月開催が基本です。
東京というところはとにかく人が多いですが、IT系に限ってもイベントもまた多いところなので、「仕事帰りにふらっと寄れるイベント」を作りたいと思って、平日夜開催というのはわりとこだわってきました。
でも、週末の方が時間取れるなーとか、ガッツリ作業する日もあったほうがいいなーという方もいるかなということで、最近はHackFestという形の、週末の午前中集合でランチを挟んで夜までというイベントもやるようにしてきました……というのが今年の進展でしょうか。
あとセミナースタイルというのはどうしても登壇者と聴衆って感じになってしまう感があって、それからの脱却ということで、平日夜のもくもく会というのも最近はやってます。本当はワークショップとかもやりたいのですが、これは仕込みが大変だなあということで、実現できてない……ですね。
スタイルを固定化しないというのも人集めには不利なんでしょうけど、しょうがないですね、これは。
まとめ
関東オフは今年で2年ちょっとになるわけですが、月一、平日夜開催というスタイルから、いろんなスタイルを模索し始めたところが今年の展開です。割と色んなことができて、個人的には満足しています。
一方で、立ち上げたときから、それぞれのイベントを開催して、（大抵は）なんかしゃべって、ということを一人でやってしまったので、関東オフは私の色がかなり強く出たイベントに外部からは見えてしまっているのかなあというのは、わりと悩んでいます。といって、人に仕事をお願いするのがとっても苦手なので、ズルズルと来てしまってるというのが今年の反省。
来年こそは、自分カラーを薄めたいなあ、と思っているところです。
ま、ともかく、そんな感じでやっているので、興味がある方、時間があえば遊びに来てくださいね。
明日はKenichiro MATOHARAさんです。よろしくお願いします！
*1:コミュニティコミュニティうるさいですね、すみません。
LibreOfficeバグハンティングセッションのご紹介
この記事は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年のMongoDB JPを振り返る
この記事はMongoDB Advent Calendar 2014の6日目です。残念ながら昨日書く人がいなかったので途切れてしまいました。あとからでも書いてくれる人が出るといいな。
さておき。
私は正直、技術的にガッツリMongoDB使い込んでるわけではないので、非技術的なことを書きます。私が書けることといったら、コミュニティトークぐらいしかありません。そんなわけで、今年のMongoDB JPの活動について書きましょう。
MongoDB JPとは
公式サイトから一部引用。
目的
MongoDBユーザによるMongoDBユーザの為の会です。
MongoDBは2013年現在、世界で最も注目を集めているNoSQLです。
これを日本で普及させると共に、その日本での地位を確固たるものにする事を目的としています。活動内容
- MongoDBを普及するための各種イベント（他OSSとの交流、独自セミナー、等）の開催
- MongoDBに関する技術情報の日本語化作業（ドキュメント、Webinar、Webサイト、等）
- MongoDB技術者、及び利用者間の交流の促進（ハッカソン、トレーニング、勉強会、等）
- 開発元である10gen社とはマーケティング面での協業/連携（MongoDB Tokyoの開催、パートナー企業の支援）
（今見たら昔から改定されてないから、MongoDB Inc.が旧社名10genのままになってる）
ということなんですけど、まあMongoDBを日本で盛り上げるためにいろいろ手弁当でやりましょうよ、ってことですね。その意思に賛同する方、ぜひMongoDB JPのGoogle Groupに参加してください！！
私はMongoDB JPの中では特に何か役付というわけじゃなくて、まあ、平たくいえばお祭り担当なんですけど。お祭り担当楽しいですよ。こちらも賛同者募集中。ということで、今年の活動を紹介します。
秋のもんご祭り
公式サイトなど。2013年は夏祭りだったのですが、今年は開催が秋になりました。
これについては私なにもしてないんですけどね。ほとんどMongoDB JP会長の窪田さんと、協力のエムキューブ・プラスハートさんにお任せ。何から何までお疲れさまでした。ありがとうございました！
私は展示側だったのであまりセミナーとかは聴講できなかったんですが、ブースにも結構人きてくれて、いやー、楽しいイベントでした。来年もやるのかな？ やりたいですね。やれるといいですね。
手抜きをして当日の私のTwilog貼ります。写真いくつか上げてあるので、雰囲気を感じていただけると幸いです。検索すれば参加者の方のブログとかも出てくるのではないかな？
丸の内MongoDB勉強会
これはMongoDB JP中核メンバーの渡部さん、林田さんのお二人が頑張ってくださってるイベントです。イベントページ。お二人の勤務先である野村総合研究所（NRI）の丸の内の会議室をお借りしてやっているのが名前の由来です。今年は第16回から第20回まで、大体2ヶ月に一度のペースで開催されました。
ハンズオンありきで基礎を確認、そしてレプリケーションやシャーディングを、参加者同士協力しあって体験できるとても楽しい勉強会です。トークも毎回充実。過去の資料はgithubで公開されているので予習復習もばっちり！
終わったあとはだいたい飲みに行くので親睦も深まりますよ。東京地区の方、ぜひぜひ参加を！
オープンソースカンファレンス
今年はMongoDB初めての試みとして、春のOSC東京と、夏のOSC京都に参加しました。こういうことを提案するのは、だいたいおっちょこちょいの私です。
春のOSC東京では前述の渡部さんが登壇してくださって、押すな押すなの（いや、それは言いすぎか）大盛況だったそうです（私はブースでお留守番）。ブースにもたくさんの方がきてくれました。チラシ200枚ほぼ配布終了……だったかな？ 詳細は私のウソ英語（苦手なんですよ……）で書かれたブログを参照、とこれまた手抜きですみません。英語はデタラメですが、写真見て雰囲気をお楽しみください。
夏の京都は私と、昨年「納涼もんご祭り」のディレクターを務めた福崎さんの二人で、二日間の日程のウチ土曜日のみ参戦。発表は私がやらせていただきました。ブースにもたくさんの方にお越しいただいて、100枚刷ったチラシがほぼなくなりました。Facebookを漁ったらめっちゃ疲れた私の写真があったので張っておきます。ははは。
来年の春のOSC東京、どうしようかなあ。手伝ってもいいよ！って方、ご連絡ください。
その他の活動
db tech showcaseとかは厳密にはMongoDBの活動ではないですが、MongoDB JPなメンバーも出てますね。その他主要メンバーは徳島とか広島とか呼ばれて参加しています。自分の地元でもMongoDBの話を聞いてみたい！勉強会をやってみたい！という方は、とりあえずMongoDB JPのGoogle Groupsに投げ込んでみるとよいかもしれません。東京地区以外でも定期的な勉強会とかあるといいですね。
Google Groupsも困りごと相談窓口やその他として、うまく機能してると思います。なにか悩んだこと、困ったこと、相談したいこと、こういうことできたらオモロイな？ってことがあったら、ぜひ投げ込んでみてください。逆に、「あ、これなら自分も答えられるかも？」と思ったら、ぜひぜひ回答してみてください。
忘れてはいけないFacebookのMongoDB JPページ。MongoDBを始めとする、クラウド、ビッグデータ、分析などのテクノロジーについての情報や、日本国内のコミュニティについてのポスト（は、私によるものです）があります。Facebookアカウントをお持ちの方は、ぜひ「いいね！」してください。
おわりに
ということでMongoDB JPの活動内容でした。来年もいろいろやっていきたいと思いますので、「手伝ってもいいよ！」という方はぜひ名乗りをあげてください。
明日はtetorさんの「PHPドライバでレプリカセットのフォールバックができなくてハマった話」だそうです。お楽しみに！
LibreOffice Conference 2014 Bern参加裏レポート
こんにちは。この記事はLibreOffice Advent Calendar 2014の初日です。すっかり忘れてたなんてのは秘密ですが、公開遅くなりましてすみません。
さてさて、今回はちょっと今更感もありますが、LibreOffice Conference 2014 Bernの参加「裏」レポートです。裏というのは、表は日経IT Proさんに書かせてもらったからです。
カンファレンスの内容とかは色んな所でしゃべったりなんだりしたので（聞きたいという人は呼んでください ^^）、ここは裏レポートというだけあって、準備とかオフタイムとかなんとかそういう話。
お金とかそういう話
今回のカンファレンス会場はスイスのBern（日本だとベルンと表記されるけど、向こうの人はバーンって発音してたと記憶してます）。スイスといえば美しい自然、観光地として外国人を暖かく受け入れてくれる人柄、美味しいチョコレートと乳製品、などが浮かびますが、もうひとつ、とにかく物価が高い、って印象があります。航空券とかホテルとか高そうってイメージがありました。
では実際のところ、かかった費用ってどんなもんでしょ？ 見てみましょう。あ、スイスフランで支払った分は、今のレートで計算してます（当時のレートなんか忘れた）。
| 費目 | 金額 | 備考 |
|---|---|---|
| 航空券 | \147,630 | タイ国際航空 成田 - バンコク - チューリッヒ 往復（エコノミー） |
| 鉄道 | \7,800 | SBB チューリッヒ - ベルン 往復（二等車） |
| 鉄道（追加） | \6,000 | 帰りのみ、一等にアップグレード |
| 宿泊 | \34,620 | 6泊（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時に家出て、朝の冷たい空気の中を歩いて行くのは気持ちよかったです。帰りも歩いてたけど、毎日飲んだくれてて遅い時間だったから、道によっては結構暗くて怖かったｗ
- お部屋は普通の何室かあるアパートの一室を貸し出す感じ。他の部屋はホストやその相棒が使っているそうです（ここは彼らのオフィスで、お家は別にあるので、毎日来るわけではないとのこと）。そういう意味でバストイレが共用なので、タイミングを見計らう必要はあります。
- そしてぼくは同居人がシャワーを浴びてる最中にトイレに行きたくなり、ぴょんぴょん飛び跳ねる勢いで我慢したことがあります。トイレは行けるときに行っておきましょう。
- 毎日遅く帰って早く出かける日々だったのでホストとゆっくり話す機会があんまりなかったのは少し残念。せっかくのAirBnBなので、そういう機会を作っても良いかもね。
観光とかとか
ベルンはあんまり大きな街ではないので半日ぐらいで一回りできます。とっても良い街なので、行ったらぜひ観光しましょう。カンファレンスのローカルチームが、イベント終了後の9/7（土）にツアーを企画してくれてたのですが、私は残念ながら土曜日の飛行機だったので参加できませんでした。もし可能なら、日程合わせて参加すると二倍楽しいと思うので、みなさんはぜひ。
そのかわり、月曜日の朝に着いたので月曜日はフラフラと一人で歩きました。でも月曜日だと博物館とか全部しまってて残念。写真とかは機会があったらいずれ。
面白かったのは、昼ご飯食べたあと一旦駅に戻ってきて、トイレ行こうと思って構内を歩いてたら、LibreOfficeのTシャツを着た人が前を通りかかって「あれっ」と思ったら、それがThe Document FoundationのFlorianとAlexの二人だったというね。ベルリンで一回あったきりなので、声をかけたとき向こうはぼくのことわからなかったみたいだけど、ベルリンであったよね！って言ったら、ああお前か〜ようこそベルンへ、ってなって、ホテルまで遊びに行きました。で、その後みんなでご飯を食べに行くという展開に。全然観光じゃないな。
言葉とか
カンファレンスは公用語は英語ですが、多くはネイティブではないので安心です（なんだそりゃ）。まあ共通の土台はありますし、なんとかなりますよ。てきとう。そもそも、なんともならないと思う人は行かないと思うので。
今回はLTしましたが、その話はまた別途。あとQA roundtableでは「日本からはなんか意見ない？」って聞かれたりして適当に答えたりしました。ヨーロッパ人が多いLibreOfficeコミュニティにおいて、日本から来ている、というのはそれだけで価値なので、向こうは話を聞こう、理解しよう、というバイアスが結構かかっていて、その点は楽ではあります。
街歩きしたりご飯食べたりという点についてですが、ベルンはドイツ語圏なのでドイツ語ができたらそりゃいいに決まっています。けど、観光地なので大抵の人は英語しゃべれますので、その点は安心。同じアジアなのに、北京で絶望したときに比べれば格段の差です。
LTの話
というわけでやったわけです。LT。
これも、「せっかく行くのだからなんか喋ったりできないかな」ってついったで書いてたら、それを読んでたからだと思いますが我らがCalc HackerであるKohei Yoshidaさんが、Hack Nightのときにライトニングトークの取りまとめをしてたJan (Kendy) Holesovskyさんにつないでくれて、それで「じゃ、明日よろしくね！」ってことになったわけです。
資料はこちら：
最初自己紹介とかダラダラ書いてたら「君、5分しかないって分かってるかい？」ってKendyに怒られましてｗ、そりゃそうだと思ってガサガサ削ってこうなりました。でも向こうのLTってわりと1枚のスライドを丁寧にしゃべってスライド2〜3枚ってことが多いみたいで、Koheiさんによると「なんで彼はあんなにスライド急いでめくるの？」って聞かれてたそうですｗ
まあ実際のところ準備不足も甚だしいし、練習なんかまったくしてないからスライドとにらめっこで聴衆の方見る余裕ないし、いろいろ酷くて、すっごい落ち込んで、あーだめだ、もうつらい、って頭抱えてたら、「さっきの話、面白かったよ」「続き聞かせてよ」って席まで来てくれる人がいて。はー。うれしいですね。
ここで満足して英語の勉強しないので上達しないんですが（こら）、でも、概ね受け手は優しい。これは主張しておきたいです。はい。
まとまってないまとめ
多分LibreOffice Conferenceはしばらくはヨーロッパを巡回することになると思います。この点はお酒飲みながらでも話題になったのですけど、やっぱりコミュニティの強さとか色々考えると、TDF（ドイツ）やLibreItalia（イタリア）、それからCollabora（イギリス）があるヨーロッパ*1 の強さは光りますわね。サポートベンダーの層も暑いし。
で、ダイバーシティは、TDFからの旅費補助によるカンファレンスへのローカルメンバーの誘致とか、あと地域カンファレンスに中核メンバーが参加するなどといったことで確保するほうがいいんじゃないか、という。
これは地理的・参加者の旅費補助費用とかの問題だけじゃなくて、例えば日本でLibreOffice Conferenceを開催したとして、日本のエンドユーザーが英語トラックを聞きに来るか、それを聞いて満足するか、それが日本コミュニティを盛り上げることにつながるのか、ということを考えると、まあそうだよね、という。我々はコンシューマプロダクトを扱うコミュニティなので、コンシューマにとって国際カンファレンスをやることが意味があるか、というのは考えなければいけないですね。
でも日本からの情報発信というのはとても期待されていて、とくに事例を発表できる人、旅費補助はするからぜひ来て欲しい、と色んな人にいわれました。来年はデンマークです。ぜひ皆さん、ご検討ください。
さて、初日終わり。明日は榎さんです。よろしくお願いします。
*1:イギリスはヨーロッパじゃない、とかいう話はおいといて。
うぶんちゅ！ まがじん ざっぱ〜ん♪ vol.2
ちょっと出遅れ気味ですが告知。
Ubuntuなゆかいな仲間たちの同人誌、『うぶんちゅ！ まがじん ざっぱ〜ん♪ vol.2』に、光栄なことに声をかけていただきまして寄稿させていただきました。
最初、声をかけていただいたのはよいけど、何書こうかなぁ〜って結構悩んでたのですが、Ubuntuは10周年だというけど、気づいてみたらCUPSも15周年じゃないか、じゃあCUPSとUbuntuの歴史を振り返るとかいうネタでいいですか、いいですよ、じゃ書きます、ってことで書きました
ぶっちゃけ誰が読むんだこの記事、と我ながら思うんですけど、同人誌なんだから自分の好きなこと書いていいよね、と。
歴代のUbuntuをダウンロードして仮想マシンで動かして印刷周りのパッケージのチェックしてスクショとって、ってのはけっこう手間だったんですが、自分でも知らなかった頃*1 のCUPSや他の印刷スタックのことを遡っていくのはなかなか個人的には面白い体験でした。ちょっと失敗だったのはGhostscriptの悲しい歴史（ESP GSがなくなってGPL GSにマージされて日本語レンダリングのコードがドロップされて復活したあたり）を書き忘れたことなんですが、まあ、それは今更だしいいよね。
正直、もう印刷まわりのことを追いかけるのはやめようかなと思っていて、これが最後の記事になるかなって思いながら書きました。そういう意味で、私としては満足しています。
その他の皆さんの記事もすごい力作ぞろいで、私がここでダラダラ書くより体験版(PDF)を読んでいただいて、おっ、っと思うものがあったらぜひ買って読んでほしいなあと思います。700円はお買い得ですよ。いやほんと。個人的お気に入りは、ゲストページになりますがおしえさんの「普通の大学教員が【Ubuntu】やってみた。」です。こういう自分日常でUbuntu（に限らず、オープンソース）で暮らしてるよ、っていう記事はもっともっと読みたいですね。みんな書いて。
上の告知にもあるとおり、販売はGumroadですが、Amazonギフト券でも購入可能です。詳しくは告知ページをよくよく読んでね。
