ただのにっき

■ OSS Gateワークショップにメンターとして参加してきた

(だいぶ間があいてしまった。これを書いてるのは翌週の水曜日)

以前書いたOSS開発者を増やす活動「OSS Gate」、その最初のワークショップを開催した(OSS Gateワークショップ2016-01-30)。メンターとして参加。

まずはやってみよう、という趣旨ということもあってあまりバンバン宣伝したわけでもないので、「OSS開発をしてみたい人」である参加者は4名。これに1.5倍くらいのメンターがいて、トライアルとしてはちょうどいい塩梅だと感じた。

あらかじめGitHubのアカウントだけ作っておいてということにしておいて、基本はworkshopリポジトリに参加者ごとの作業メモ用issueを作ってがんがんメモを書いていくというスタイル。それぞれの参加者にどんなことがやりたいかインタビューしてみたらLinuxカーネルを直したいなんて人もいてびっくりしたけど(笑)、それぞれに自分が普段使っているライブラリやフレームワークをチョイスしたようだ。

おれがついたakito19はruby-pgを選んだんだけど(ruby関連になったのは偶然です)、そもそもgemを単体で使った経験がほとんどないないらしい。ふだんはRailsアプリでActiveRecord経由なんだろう、なるほどおもしれぇなぁ。issueのログにはないけど、エラーが出たら(メッセージを読まずに)いきなりソースの該当行あたりを読み始めたりして、ふだんはどういう開発環境に身をおいているのか、横で見ているだけでいろいろわかることがある。

で、どこに目をつけたらいいか、ちょこちょこヒントを出しながら進めていって、最終的にはドキュメントとテストコード*1それぞれに1件ずつプルリクを出すことができた。どちらもすぐにマージされたようだ。OSS開発者デビューおめでとう！

なにがたいへんって、教えすぎないように自重するのがもうたいへん。できるだけ自力でたどりついて欲しいからすぐに正解は明かしたくないんだけど、明らかに困ってる人を前に手を差し伸べずにいるのも難しくて、その匙加減がほんま難しいわ。というわけで、むしろこっちが勉強になった感がある。

いちおう隔月でやろうということになったので、奇数月の最終土曜日固定で2回先まで予定を決めた。次回は3/26*2。ちかくにOSS開発者予備軍がいたら声をかけてあげてください。大学生、高専生あたりがいいと思うけど、社会人でもぜんぜんおっけー。メンターに怖い人はいません(たぶん)。質問などはGitter上にチャンネルがあるので、そこで聴いてもらえると良いかと。

■ デレステイベント「パステルピンクな恋」

Z5 Compactへの移行でプレイできない時間がけっこうあったばかりか、その後チューニングが出なくて数少ないMASTERがほぼ封じられた状況だったが、なんとか5万位以内入賞で紗枝はん2枚GETできた。ふー。

Z5cでのプレイでスコアが出ないの、たぶん2つの理由があって、

• 画面サイズの違い。Z5cの方がちょっと大きいので、指を乗せる部分がわずかにずれていて、それに身体を合わせられずにいる。人間ってデリケートなのね……。これについては徐々に慣れてきた感じがあって、スコアはだいぶ向上している
• アプリの認識ミスがある。これは多くの人が多くの端末で「ある」と言ってる現象だけど、明らかにタッチしてるのに認識されないことがけっこうある。NICEやBADなら自分のせいだと思うけど、MISSはおかしいもんな。

後者がどうにかならないと、MASTERが怖くてできない*1。でもまぁ、これだけバリエーションのあるAndroid端末でここまで性能を出してきてるんだから、あんまり責められないんだよなぁ。デレステはAndroidアプリの中でも最高品質の部類のひとつだと思うし、ここまで仕上げてきてる開発者を尊敬してる。ので、がんばってください。

THE IDOLM@STER CINDERELLA MASTER Cute jewelries! 002
歌・トーク:三村かな子(CV:大坪由佳)、輿水幸子(CV:竹達彩奈)、佐久間まゆ(CV:牧野由依)、緒方智絵里(CV:大空直美)、小早川紗枝(CV:立花理香)
日本コロムビア
￥1,657

■ 佐川急便と日本郵便の双方で有効な伝票番号がある

宅配トラッカーで「佐川の番号を入れたのに(配達済みの)日本郵便のステータスが表示された」というレポートをもらって、調べてみたら本当に両サービスで有効な番号だった。そりゃダブることはありえると考えてたけど、本当にあるんだなぁ。どっかの桁で業者識別できるようにしてくれればいいのに……。

で、とりあえず応急措置的に検索順序を逆にして佐川を先に見つけるようにした直後、こんどは新しく発行された自分宛ての荷物の伝票が逆パターンになっていて、なんというかタイミングが良い。いや悪い。やっぱり応急措置って長続きしないんだなぁ(笑)。

結局、ライブラリの方では全サービスを同時にスキャンするためにマルチスレッド化した上で「複数見つかった場合は配達済み伝票を無視する」という実装にして、アプリの方では「それでも配達済み伝票が得られた場合は他のサービスが登場するまで未解決状態にする」*1という実装にして運用してみることにした。

言うまでもないが、複数サービスで同時に「生きてる」伝票が発生した場合にはこの運用だと崩壊してしまうのだけど、どうなるかなー。これまでの事例だと両者の間には一ヶ月近い時間差があるんだけど、たった2例じゃなんの根拠もないし。