groonga-normalizer-mysql パッケージをsalsa.d.oに移行する作業をした。
salsa.d.oにインポートしてもらう必要があるので、ついでにgbp import-dscでリポジトリを再作成も。 いろいろ古くなっていてlintianがレポートしてくれているやつをもろもろ修正。
@henrich さんにsalsa.d.oへのインポート作業をお願いした。
OpenSSL 1.1.0cな環境でrvm install 2.3.2
はじめに
ruby 2.3.2がリリースされたので、何も考えずにただrvm install 2.3.2したらOpenSSLがらみで失敗した。 環境はunstableなのでapt install libssl-devすると1.1.0c-1がインストールされている。問題はこいつである。
解決策
同僚に教えてもらった。
rvm install 2.3.2 -C --without-openssl
でopensslを無効にしてインストールする。 opensslのgemをダウンロードして別途インストールするというからくり。 この記事を書いている時点だと2.0.0.beta.2のようだ。
あとは、global環境にgemsetを変更する。
rvm gemset use global
globalにしないと新しくgemsetを作ったときにopensslがインストールされていないのができてしまうから。
gem install --local openssl-2.0.0.beta.2.gem
としてローカルにインストールする。
あとはうまいことインストールが完了まで待機すればよい。
OSS Gateワークショップ(2016/07/30開催)に参加した感想
クラウドワークスさんにて開催されたOSS Gateワークショップに参加してきました。その際のメモをつらつらと。
どんなイベント？
OSS Gateワークショップ 2016-07-30のイベントのページにいろいろ説明があるので、詳細は割愛しますが、一言で説明すると以下のとおりです。（イベントページより引用）
「OSSの開発に参加する」を実際に体験するワークショップです。
これにメンター（ワークショップ初参加でひよこメンター）として参加してきました。
実際の参加者は申し込み人数の半分くらいで、きっとみんなポケモンをどうにかするのに忙しいので（以下略）
参加者の立ち位置
ワークショップでは立ち位置が参加者によって異なります。
- ビギナー：OSSの開発未経験な人。
会場には普段は組み込み開発をしている人や、Web系の人、フリーランスのエンジニアの人など、様々なバックグラウンドをもっている人が参加していました。「OSSの開発に参加する」を実際に体験する人達です。
- メンター：OSSの開発経験者。
以前のワークショップに参加した人だったり、普段からOSSの開発が生活の一部になっている人。
- サポートメンター（仮称）：メンターのサポートをする人。
会場をするすると回遊し、通りすがりのメンターとしてビギナーに的確なアドバイスをして去っていく。エリアマネージャーみたいな人。
サポートメンター（仮称）は今回からはじまった制度なんだそうです。
- 進行役：司会者兼、全体に気配りもする人
イベントの進行を采配しつつ、人が足りていないところにするっとメンターとしてサポートをこなしたりするスーパーマン。
どんな風にすすんだのか？
まずは司会進行役のすとうさんから、イベントの説明があった後に、ビギナーさんと相談しつつ、題材となるOSSを決めました。
ここで注意しないといけないのが、メンターの関わっているOSSを薦める（誘導）のはあまりよろしくないかも知れないこと。
よく知っているOSSを薦めてしまうと、（メンターがそのOSSをよく知っているがゆえに）知らずしらずのうちに、わかっていることを先まわりして「答え」として教えてしまい、ビギナーが体験する機会を奪ってしまう可能性があります。
幸いにして、ビギナーの人がRails5試したいです！（ただしWindowsで）ということだったので、そちらの轍は踏まずに済みました。 それでもところどころ、先にこうすればいいんじゃないですか、と言いそうになってしまいそうになったことが何度かありました。
ただ、ぐっとそこはこらえて、ビギナーさんがはまって、これはフィードバックするチャンスポイントだね、というのを暖かく見守るというのをやっていました。
あとはビギナーさんが、作業ログ（これはビギナーさんに都度自分がやろうとしてしていることを細かくメモしてもらう）をつけてなさそうだなーというのがあれば、いまどんな感じですかというのを確認しつつ相談にのったり、記録を促したりというのをやっていました。
ふりかえり
午前中の作業が一段落したときに、「ふりかえり」をしました。これはメンターが別の島（メンター2名、ビギナー4名のグループが1単位）へと席を移動して、担当していなかった別のビギナーさんに作業を説明してもらって、アドバイスをするというものです。
立場の違いによってやることも違います。
ビギナー：自分のやったことを知らない人に説明する。OSSの開発では、ネットごしでのみやりとりすることも多いため、暗黙の了解ではうまくいかないことがある。説明を省略してしまうと、空中戦が発生したりと無駄なやりとりをしてしまうことになる。このとき作業ログを活用することで「何をやったのか」あるいは「何をやっていないのか」を伝えることの大事さを実感してもらう。
メンター：担当していなかったビギナーさんの説明を聞いて、メンターとしての視点からフィードバックする。
メンターとして、これを実践できているのはいいね！とか、ここはこうしてみるといいよ！というのを伝えるのを意識してみたりしました。
フィードバックしよう
午前中にOSSを動かしてみて、ハマったところや、こうなっていたらいいなという「気になるポイント」をビギナーさんが実際にupstreamにフィードバックしようというのをやりました。
ただ、フィードバックを完遂するところまで一緒にできなかったのがやや心残りではあります。（フィードバックしたい内容を整理するところまではできた）
もちろん時間内にそこまでできてれば良いに越したことはありません。ですが、フィードバックを完了させることを優先してしまうと、ワークショップの後でひとりでもそれができるかは難しいような気がします。（ちょっと言い訳っぽい）
あとは英語になおすだけ、がビギナーさんにとって結構ハードル高いという。。。
ふりかえり再び
また席を移動して、別のビギナーさんとのふりかえりを実施しました。
ビギナーさんによっては、すんなりフィードバックするところまでうまくいけている人がいるのが印象的でした。メンター力の違い？
「英語つらい」にどう答えるか
これは私も英語つらいので悩ましいところです。
こんな感じのつたない英語でも大丈夫だよ、という具体例を説明したりしましたが、それでよかったのかどうか。
さいごに
他のメンターは2人のビギナーの面倒をみていましたが、私は参加人数の都合で、1人のビギナーの面倒を主にみていました。初めてのメンターとしての参加だったので、両隣にビギナーさんがいたら十分なサポートができたかはあまり自信がありません。
とはいえ、機会があればまたメンターとして参加してみるのもいいかなーと思った次第でした。(楽しかった） サポートメンター制度は次回以降も採用とのことなので、メンターをやるのにちょっと自信がないんだけど、という人でも安心です。（ふらりと現われて、的確なアドバイスをして去っていくので）
どうでもいいことですが、私以外はみなポケモンマスターだったのが印象的でした。みんな好きだなポケ（以下略）
sourceforge.netミラーの状況について
はじめに
C/C++のテスティングフレームワークにCutterというものがある。これはsourceforge.netにてホスティングされているプロジェクトである。 このプロジェクトでは年に1回くらいの頻度で新しいバージョンをリリースしている（場合によっては年2回ということもある）
sf.netのここ最近のやらかしでミラー減ってるぞというのを耳にした。 ちょっと不安になって、tar.gzのミラー状況をみてみた。
リリースバージョンとミラー状況
1.2.5 12サイトでミラーされている。
1.2.4 13サイトでミラーされている。
1.2.3 2サイトでミラーされている。
1.2.2 1サイトでミラーされている。
1.2.1 1サイトでミラーされている。
1.2.0 1サイトでミラーされている。
2世代前からミラーサイトが激減しているのがわかる。
さいごに
1.2.2以前はもうsourceforgeにしかない。1.2.2は2012年10月リリースなので数年前といえばそうなのだが、古いアーカイブもきっちりミラーされているという勝手な思い込みは幻想でしかなかった。 ほかのホスティングサイトならどうだというのは調べていないので、sf.netが他と比べてどうだとかいうつもりはない。 あくまで、現状こんな感じなのかという気付きをメモしたまでである。
Groonga on ARMパッケージの最新版(5.1.1)がp.d.oに入りました
しばらく前から、armhf向けにDebian/GNU Linux unstableのパッケージを実験的にひっそり提供していました。
apt-lineに以下のようなエントリを書いておけば、aptでインストールできるようにしていた、ということです。
deb http://packages.groonga.org/armhf unstable main
この度、現時点の最新版であるgroonga 5.1.1とgroonga-normalizer-mysql 1.1.0がunstableにはいったので、今後はそちらを使うようにしてください。 つまり、/etc/apt/sources.list.d/以下のapt-lineの設定はいらなくなります。
ちなみに、testingにも入ったのでうまくいけばstretchにも同じものか、より新しいバージョンが提供されることになります。多分。
ながらく更新できてなくて4.0.6のままだったので、ようやく追いつきましたね。
Groongaのコンパイル時にmax-gcse-memoryを指定してみた
はじめに
Groongaをコンパイルしているとこんな警告がでていることに気づく。
warning: const/copy propagation disabled:
これはGCSEというやつで、最適化が無効になったという警告である。 無効になってしまったんなら、そこはなんとか有効にしてあげたくなるというのが人情というものである(適当)。
Optimize Options - Using the GNU Compiler Collection (GCC) を読むと、必要なメモリを確保できなくて最適化を諦めたとある。 ならばパラメーターを明示的に指定してもうちょっとGCCに頑張ってもらおう。
そのためのオプションもある。それがmax-gcse-memoryである。
--param max-gcse-memory=
デフォルトが128MBらしい。それを超えてしまうと、断念してしまうようだ。 デフォルトの値を超えることってそんなにはないだろうが、それをGroongaさんは超えてしまった。
max-gcse-memoryを指定してコンパイル
適用するのにlib/Makefile.inにひとまず直に書いて試した。
CFLAGS = @CFLAGS@ --param max-gcse-memory=268435456
これによってコンパイル時間が増えるだろうと思ったらせいぜい1割増程度だった。
適用前
V=1 make 2>&1 258.80s user 18.57s system 96% cpu 4:46.33 total
適用後
V=1 make 2>&1 269.90s user 32.32s system 97% cpu 5:10.68 total
ベンチマークをしてみる
どれくらい効果があったのか、ベンチマークをとってみることにした。 幸いにしてGroongaにはbenchmarkが付属している。この結果を比較すればよいはずである。
- Groonga 5.1.1
- Intel Core i5-2467M CPU @ 1.60GHz
- メモリ8GB
- 10回試行し、その中央値をそれぞれプロット
- Original versionというのが普通にコンパイルした版
- Modified versionというのがmax-gcse-memoryをカスタマイズした版
見事にほぼどんぐりの背比べである。なかには変更後のほうが妙に遅いケースもみられる。
まとめ
片手間にとったベンチマークとはいえ、残念ながらちょろっとコンパイルオプションを変更して速くなるかというと、そうでもなかった。 そんなに甘くないのが現実である。
