なるひこの Linux Printing お勉強日記 RSSフィード Twitter

ご注意!

ここはあくまでも私個人のブログであり、いかなる団体や組織の立場から離れた、私個人の知見なり学んだことなり勝手な思い(妄想ともいう)を書く場所であります。それを踏まえてお楽しみいただければ幸いです。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツはすべて クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。

2015-12-09

はてなブログにお引越ししました

すっかり告知するの忘れてた。ここはもうメンテされる予定はありませぬ。

http://naruoga.hatenablog.com

をよろしくです。

2015-03-31

転職します

以上。終わり。

……でもいいですが、もうちょっと追記。

3月31日付けでミライト情報システムを出て、4月1日から新しい仕事につきます。


入社のときのエントリーを見ると色々気恥ずかしいですね。3年に満たない期間で離れてしまったのは、まあ、勤まらなかった、といえばそうです。これに関してはなにを書いても言い訳っぽくなるのでやめます。

前職はいわゆる揶揄されることの多い中堅どころの「えすあいやー」であって、そういうところにはITを専門に学んできてない人がいっぱいいて、仕事にも技術にも興味なんかぜんぜんなくて、でもデスマって消耗してるって、ついったとか見てるとそんな感じですよね。

でもそんなことなくて、技術や業務知識について学習意欲もあるし実力もある特に若い層が結構いて、あるいは育っていて、中堅どころもそれぞれに持ち味もあって、上は面白いことに関心があったり本人が面白かったり(ぉ、すごくいい職場でした。一緒に働くことができて幸せでした。えすあいやーを十把一絡げに悪くいわないで欲しいなあ、と思ったりしました。

ぼくの立ち位置は社内R&Dというか、自分のチームでやってることの先行技術探索とか、そのためのちょっとしたプロトタイピングとかで、それはとても面白い仕事でよかったんだけど、そんなにお金儲かってない中でなんでぼくがそんな仕事させてもらえたかっていうと、それは単純にぼくが体調を崩してしまったので納期がタイトな仕事をやれなかったという点もあって、ね。フクザツではあります。

知ってる人は知ってますがぼくがMongoDBと関わったのはこれをビジネスにしようという動きがあったからです。今の会社辞めるので仕事的には縁が切れます。けど、MongoDBは好きだしMongoDBを通じて知り合った人たちともこれからも仲良くなんかできたらいいなとは思ってます。


転職……ということなので、次の仕事は決まってます。というか明日初出社なので日記なんか書いてないで寝ないといけません。

普段のぼくなら社名をじゃじゃーんと書きたいのですが、正直、まだ自分に自信が持てないというのがあります。健康不安を抱えつつ、ほんとうに新しい会社にコミットできるのかどうか。なので、自信が持てるまでは、隠すわけではないけど、大々的に書くのは控えようかなと。

ただ、新しい会社でやっていることが本当に面白そうで興味を持てて、こういうことをやっていれば健康面でもプラスになるんじゃないか、って思ったのはそうです。それと、健康面にも不安があるということを伝えてなおかつ一緒に仕事をしたい、という、とてもありがたい言葉をもらいました。ですから、自分と周りと相談しつつ、今の(残念ながら)悪いループから抜けだすチャンスだと思っているので、そうなったって自分に自信を持てるようになったら、もっと堂々と「こういう会社でこういう活動をやってます!」っていおうと思います。いえるようになるべく、ぼちぼちやりますね。

それと、各種コミュニティ活動についてはむしろ推奨という感じに受け取っているので、そっちのほうから自然に名前が出るかもしれません。というか、出るといいですね。


そんなわけで、とりとめもありませんがよろしくお願いします。ぺこり。

2015-01-30

デザパタを一人でこっそり振り返ろう #5 (Singleton)

なんと前の記事を確認したら3年近く前だよ…… orz

この連載?は、へっぽこプログラマー(厳密には足を洗ったので「元」)のぼくがひょんなきっかけから、Javaプログラマー向けデザインパターン入門書として有名な:

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

(以下 JDP)を買ったはいいけどなんかやる気なくて放置してたところに、これまた Smalltalk 界隈の人に教えてもらった:

Design Patterns Smalltalk Companion, The (Software Patterns Series)

Design Patterns Smalltalk Companion, The (Software Patterns Series)

(以下DPSC)を買って読んだらむちゃくちゃ面白くて、じゃあ JDP の内容を Smalltalk で実装したあと、DPSC を答え合わせ的に読む、ということをやったら自分の勉強になるし、「動的言語におけるデザインパターンは静的言語のそれと違う」って意味が噛み締められるんじゃないかと思って始めたものです。

過去の記事は次のとおり。

ということで今回は 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) のデザインパターン

のページ 127 にあるパターンって意味です。はい。

とにかく本当はグローバル変数に突っ込むのは良いやり方ではないけど、Smalltalk ではそういう例がいっぱいあるってことはわかった。

シングルトンのバリエーション

シングルトンには persistent (永続)、transient (一時的)、single-active-instance (単独アクティブインスタンス) の三つのバリエーションがあるとのこと。

  • 永続シングルトン - 特定のクラスの唯一のインスタンスであり、なおかつ永遠に変わらないもの。
  • 一時的シングルトン - あるクラスの唯一のインスタンスだけども、インスタンスは変わりうるもの。例えばセッション情報を管理するオブジェクトはシングルトンであるが、セッションが破棄されると破棄され、新規にセッションが起きると再生成される。
  • 単独アクティブインスタンス - あるクラスに対し、アクティブまたは有効であるインスタンスは一つだけだが、インスタンス自体は複数存在するもの。例えば IDE のプロジェクトを管理するクラスがあるとして、IDE は複数のプロジェクトをオープンできるのでインスタンスは複数存在するけど、実際にプログラマーが弄ってるプロジェクトに対応するプロジェクトだけが有効とかそういう。実際にはシングルトンではないけど、性質的には似てるから一緒に論じますよと。
予約語

Smalltalknil, true, false とかは実は UndefinedObject, True, False という「クラス」のシングルトンオブジェクトとみなせますよと。実際 true をインスペクトすると True ってクラスのオブジェクトだよって言われるしね。

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パターンだそうです。お楽しみに。

2014-12-21

関東LibreOfficeオフラインミーティングとはなにか

この記事は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-09

LibreOfficeバグハンティングセッションのご紹介

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

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

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

たったこれだけ!です。


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

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


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

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

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

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

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


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

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

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

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

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