息をするようにCPANにモジュールを書けるになった経緯とその結果起こったこと分かったこと

Hokkaido.pm #12

Nov 1st, 2014

Profile

• id: Songmu (ソンムー)
• Masayuki Matsuki
• おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
• https://metacpan.org/author/SONGMU
• 青ヘルの方です
• 趣味はCPANizeです
• Webアプリケーションエンジニア
• 株式会社はてな シニアアプリケーションエンジニア

青ヘルの方です

謝辞

• Japan Perl Association
• Hakkaido.pmの皆様
• クリプトン・フューチャー・メディア株式会社

My CPAN Modules

• 50超え
• App::RunCron
• Riji
• DBIx::Schema::DSL
• Cache::Redis
• Config::PL
• Redis::LeaderBoard
• Parse::Crontab
• ...

本題

私とPerl

• 2000 大学時代に中国語とか言語処理とかCGIとかでちょっと使った
• 2004 中国でベンチャー(Perl 0%)
• 2005 外国語学校の営業兼情シス (Perl 5%)
• 2009 印刷系のSIer (Perl 15%)
• 2011 カヤック (Perl 90%)
• 2014 はてな (Perl 1%)

2007年 Perlを本格的に学びだす

• 2005年にレンサバ借りてMT運用くらいはしていた
• HTML/CSS はそこそこ詳しくなった(自社のサイトからテーブルレイアウト殲滅とか)
• JavaとレガシーASPとかColdFusionとかの環境に危機感
• Web業界・Perl界隈へのあこがれ
• 2007年に「初めてのPerlを購入」
• デイリーポータルviewerを作る
  • 最初はCGIだったけど今はplack化して運用中
• CPAN Authorに対する憧れ

2008年 最初(?)の転職活動

• 結婚準備と給与
• 会社にエンジニアとしてのキャリアがなかった
• 1000speakersとかに登壇したり、Shibuya.pmに参加したり外を意識しはじめてた
• 25社くらい受けて内定2社 (はてなも落ちました)
• Web企業に行けなかったけど、SIerに転職

2009年 SIer一年目

• 仕事はPHPとかVBとかレガシーCGIとか
• はじめてのYAPC
  • Plackの年
• CPANモジュールあげようと思うなど
• 初めてadvent calender書いた PerlでEmEditorマクロを書こう

2010年 また転職活動とか

• 初めてCPANモジュールを上げる(Math::CheckDigit)
• Webサービス関連企業に行きたかった
• Perlが強い会社に行きたかった
• 自分より技術力がある人がいる会社に行きたかった
• しかし就職活動は難航
• Sugamo.cssで知り合った @hokaccha にカヤックを紹介してもらう
• この年にtokuhiromに名前と顔を一致してもらう(81忘年会)

名前を覚えてもらっていたことに対する喜び

• 「あの自転車の人だ」
• 発信している人は案外見られている

2011年 カヤック入社

• ターミナルで本格的に開発したのはこの年が初めて
• typesterやmash, fujiwaraを始め、多くのスーパーエンジニアと一緒に仕事をする
• ソーシャルゲーム開発で中規模ながらそこそこのトラフィックをさばいたり

2012年 YAPC初登壇

• 年初からfluentd使ったりしてた
• CPANにモジュールを上げるペースが上がった気がする
• この頃からコミュニティから認知してもらえるようになってきた気がする

2013年 Riji書いた

• YAPCで中国語LTした
• 結構大きなゲームのプロジェクトの新規開発のリードエンジニアやってた
• プロジェクトで使うモジュールを結構書いた気がする

2014年 はてな入社

• 初めて転職に困らなかった(しかし油断はならない…)
• Scala書いてる

なんでCPANにモジュールを上げるのか

• なんでOSS活動をするのか

最初は上げたかったから

• Math::CheckDigit
• 仕事でテストバーコードを作るためのモジュール

カヤックで仕事をする上で普通に上げるようになった

• Perlで本格的にWebアプリケーションを書くと自ずと必要になった
• 使ってるモジュールにパッチを送りまくった
• CPANあげちゃおうぜおじさん業もした
  • You CPANにあげちゃいなよ

上げられるものは上げてしまうように

• 社内の情報共有のためにも有用
• 社内で何度もコピペされているようなもの
• 上げてしまっても別にノウハウの流出リスクにはならない(後述)

プロジェクトコードを簡潔にする

• モジュールは黒魔術でもいい
• Const::Commonは内部実装はちょっとカオスだけどインターフェースはきれい

去年のプロジェクトのcpanfile

• 自分のモジュール 約20モジュール
• メンテを引き継いだモジュール 約5モジュール
• パッチを送ったモジュール 約15モジュール

得られたもの

他のソフトウェアエンジニアとのつながり

• 学び
• 世界が広がった
• 違う業界の人と仲良くできたりする
• 知見を公開する人の元に知見が集まる
• p-rとかにすぐ反応してもらえる
• もしくはメンテナンス権くださいって言ったらすぐもらえる

気づいたメリット

CPANモジュールを使う理由

• 本質であるサービス開発に集中するため
• 枯れたモジュールはやはり良く出来ている
  • エッジケースのケア
  • セキュリティ
  • ORMとか作りたくない
• Perlは後方互換を気にする文化なので、たくさん組み合わせてもそうそう壊れない

モジュールの採用基準とオープンソース戦略

• もうひとつの知られざるオープンソース 〜 ウェブ企業のOSS戦略
• 自分がソースが読めるもの
• なるべくコントロール(協調)可能なもの
  • 外部の開発者との連携
• 主体的、中心的にOSSに関わることで上手く利用する側に立てる
  • ← 使わされている側にならない
• Perl界はよくも悪くも日本語で協調しやすい
• とりあえずパッチを送ってみる

CPANにモジュールを上げる理由

• 自分で上げてしまえば、主体的に関わる側に立てる
• 抽象化できてHackishなコードはCPANに上げてしまう
  • プロジェクトのコードベースを読みやすく、ミニマムに保つ
  • 余計なリファクタループを避ける
• 社内横断的に利用する上でもCPANに上げてしまうのが最適解
  • 社内モジュール化は管理コストや暗黙知の増大につながる

テスト駆動とオープンソース駆動

• テストを書くことを前提にプログラムを書くと設計が綺麗になる
  • テストの書きやすさを考えると、変な結合を減らせる
• 同様にオープンソースにすることを前提にプログラムを書くと上手いこと抽象化できる
• 「これもうちょっと社内の事情に密結合した部分を消せばOSSにできるんじゃないか」
  • きれいな設計になる

CPAN Authorになる方法

CPANモジュールの種類を考える

自分の得意な領域はどこか？

• 業界標準的なインターフェース仕様の策定
• イノベーティブなモジュール
• 小さくてピリリと効くやつ
• 上手いこと組み合わせたやつ
• 既存の部分の隙間を埋めるやつ
• 既存のモジュールの使いやすいラッパー
• グルー
• 誰もやりたがらないやつ
• ニッチ

メンテナンスを引き継ぐ

• typesterとかtokuhiromからメンテナンスを引き継いでいる
• CPANにあげてないようなやつをCPANにあげて良い？って聞く
• win-win
• 自分のソフトウェアになる責任
• メンテをすることで知識が深まる

車輪の再発明を恐れない

• 案外同じ車輪は無い
• ちょっと探して見つからないってことはあまり良くないか古い
• みんな「やりたいな」と思っててやってないことある
• そういうのやったら賞賛される

良くない車輪の再発明

• 「あのモジュールよくわからないから自分が別のものをCPANに上げる」はあまり良くない
  • 既存のやつを理解していないと同じ罠を絶対踏む
  • 練習としての再発明としては良い
• 同様にパッチを送るのが怖いから別実装作るとかも良くない
• バグフィクスならともかく、モジュールに機能追加の要望を送るのはたしかにしりごむがissueとかで相談しよう
  • 新たな知見が得られることがある(「〇〇でできるよ」「筋が悪い」とか)
• オレオレじゃなくてすでにある仕組みに「乗る」ことも大事
• コミュニティマネージメント(難しいね)

disられないためには

• 「主語の大きな」モジュール名を避ける
• 端っこでやってる分にはそんなに怒られない
• 事前に誰かに相談してもよい
• そんなに怖くない

CPAN Authorは神様か?

• 完璧な神様ではない
• ギリシャ神話の神様のような人間ぽさ
• ちょっとした間違いもある
• だから貢献できる余地はある

OSSへの貢献について

OSSへの貢献とは？

• 別に堅苦しくない
• 敷居も高くない
• 使うこと「だけ」で貢献
• ただし使っていることを隠さない
• 可能なら問題や疑問を報告する
• p-rやパッチを送る

「OSSが世界を良くする」とは？

• 意識高そうで一瞬引く？
• 「世界がよくなった」としか言えないくらいの曖昧さ
• きっとどこかで何かが良くなったんだろう

OSS界隈での協調とカルマ

• なるべく協調可能なソフトウェアを選ぶ
• カルマをためる

OSSフリーライダー問題

• 「OSSを使うだけで貢献しない」とかいう人は全然分かってない
• OSSは貢献すればするほどうまく使える
  • 間違った使い方を避けられる
  • 互換性を崩されて突然死んだりしない
• 意思決定プロセスに関われる方が有利

以上

We are hiring

• はてなではエンジニアを募集しています
• scalaエンジニア
• Perlエンジニア
• 東京オフィス