多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと
YAPC::Tokyo 2019
Jan 26th, 2019
Profile
Mackerel
Mackerel
- はてな謹製のサーバー管理・監視SaaS
- 小規模から大規模システムまで
- ユーザー登録から3分でサーバー監視が可能
- 専属UI/UXデザイナーによる圧倒的な使い勝手
- 200週連続機能リリース達成
【宣伝】書籍発売中
【宣伝】みんなのGo言語
【宣伝】入門 監視
- 付録Cを執筆しました
- タイトルが不穏だという噂も
- なんかめっちゃ売れてるみたいです
本編
私の話
- 昔の自分は本当に(本当に!)大したことなかった
- コミュニティと関わるようになってから急激に成長した
- コミュニティ上で「楽しそうなこと」をやっていった
- 実力よりプレゼンス寄りなのは自覚している
- そこでレバレッジを効かせるしかなかった
- 昔は嫌だったけど少しは慣れた(おっさん化して恥じらいが無くなったとも言う)
- 今はそれなりのエンジニアに
- ナッパくらい?
- 見る人から見れば圧倒的かもしれないが、まだ圧倒的に上がいる
- 一生届かないラインとかも見えてきたけどまあそんなもん
- 無限に成長できるのはいいですね
今日話すこと
- Perlとの関わり
- Perlを書いてきた中で色々な出会いがあった
- どういう思い出があるのか
- どういう使い方をしたのか
- どういうコントリビュートをしたのか
- そこ結果気づいたこととか
Disclaimer
- 何故自分のキャリアや昔話をするのか
- エンジニアのキャリアについて皆と一緒に考えていきたい
- 決して自分のこれまでが正しかったと思わないし今後も安泰だと全く思わないがこれまでの経験を共有することはできる
- 単なる昔話にならないようにしたい
私とPerl(現在)
- 多くのCPANモジュールを無駄に上げている(質より量)
- YAPC登壇の機運を高めるために年始に新作上げました
- App::tmclean
- 趣味はCPANize (でした)
- Web+DB Press連載「Perl Hackers Hub」監修チーム
- 仕事や趣味でちょっとしたスクリプト、ベターシェルスクリプト的利用
CPANモジュールの数
MetaCPANだと68 dist
代表的なCPAN Module
- App::tmclean (new!)
- L
- App::RunCron
- Riji
- DBIx::Schema::DSL
- Cache::Redis
- Config::PL
- Redis::LeaderBoard
- Parse::Crontab
- Const::Common
- Test::Requires::Scanner
私とPerl
- 1980 生誕
- 1987 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に転職
2010年 また転職活動とか
- 初めてCPANモジュールを上げる(Math::CheckDigit)
- Webサービス関連企業に行きたかった
- Perlが強い会社に行きたかった
- 自分より技術力がある人がいる会社に行きたかった
- しかし就職活動は難航
- Sugamo.cssで知り合った @hokaccha にカヤックを紹介してもらう
- この年にtokuhiromに名前と顔を一致してもらう(81忘年会)
2011年 カヤック入社
- ターミナルで本格的に開発したのはこの年が初めて
- typesterやmash, fujiwaraを始め、多くのスーパーエンジニアと一緒に仕事をする
- ソーシャルゲーム開発で中規模ながらそこそこのトラフィックをさばいたり
- Archerメンテナ
- ISUCON1 優勝
2012年 YAPC初登壇
- WindowsからMacへ
- 年初からfluentd使ったりしてた
- CPANにモジュールを上げるペースが上がった気がする
- この頃からコミュニティから認知してもらえるようになってきた気がする
- ISUCON2 優勝
2013年 Riji書いた
- YAPC::Asia
- 「今時のカジュアルなデータベース関連開発」
- 中国語LTした
- 結構大きなゲームのプロジェクトの新規開発のリードエンジニアやってた
- プロジェクトで使うモジュールを結構書いた気がする
- ISUCON3 出題チーム(名前だけ)
2014年 はてな入社
- エンジニアFA宣言の走り
- はてなを選んだのも結構コミュニティつながり
- Perl Hackers Hub寄稿
- Mackerel
- Go/Scala(最近Scalaは全く書いてない)
- OSSプロダクトのメンテナンス
- 東京オフィス一人目のエンジニア
- 初のシニアエンジニア
- ISUCON4 本戦11位
2015年 Mackerelディレクター
- チーフエンジニアと兼務
- 年間23登壇
- YAPC::Asia 2015「Mackerel開発におけるScalaとGo、そしてPerl」
- YAPC::EU登壇
- ISUCON5 優勝
2016年 「みんなのGo言語」
- horenso
- Mackerel プロダクトオーナー
- はてな上場・JPA参画・CTO交代
- Perl Hackers Hub 監修チーム(主に執筆者探し)
- Mackerel LINE Notify
- ISUCON6 予選出題主担当
2017年 「Mackerel サーバ監視[実践]入門」
- YAPC::Kansai 2017 OSAKA 前夜祭
- ISUCON7 本戦3位
2018年 Mackerelプロダクトマネージャー
- Perl Hackers Hub寄稿
- 「Minillaを使ったモダンなCPANモジュール開発」
- DBIx::Sunnyのメンテ権をもらう
- ISUCON8 本戦6位
発信すること
発信を続けることの大事さ
- 2005年からBlog
- Movable Type -> Riji(2013年~)
- 7,8年やってやっとブクマなどが付くように
- 細く長くで良い
- 覚えてもらえると嬉しい
- 「あの自転車の人だ」
- 発信していると案外見られている
- 「自分のメディア」を育てる
- コンテクストを醸成する
- 開いた時にすぐに「あの人のブログだ」って思ってもらえる
- 発信していると機会が寄ってくる
アウトプット恥ずかしい話2連発
「コマンドプロンプトのdirが使えないからlsを作ったよ!」
- 2008年8月8日
dir
の結果をパーズしている
- 使えないのはどっちなのか…
2009年アドベントカレンダー初参加
- YappoさんにCodeReposのコミット権もらった
- htpasswdをメールで送って登録して貰う形だった
- TortoiseSVNでなんか上手く操作できない
- その場でmacを買いにヨドバシに走った
- なんとかコミット達成
- Macに慣れられずにそのMacは放置
思い出深いモジュールたち
Math::CheckDigit
- 初CPANモジュール
- チェックディジット計算モジュール
- バーコードリーダーハンディの仕事してた
- 依存なしで頑張ってる
- というか依存モジュールの指定方法が分からなかった
Git::Repository
- git操作のためのPerlモジュール
- gitベースのwikiを作りたくてGit::Repository::Plugin::Fileというモジュールを書いた
- Git::Repositoryの作者のBooK氏にCPANに上げることの相談メールを送る
- めちゃくちゃ丁寧な返信が届く
- この場ではお蔵入りとなったが、Git::Repository::Plugin::FileHisotryという名前で二年後にup
Archer
- deployツール
- tokuhirom ware
- 初めての社外の人へのpull request
- 後にコミット権をもらう
- この辺り(2012年頃)でいくつかのモジュールのコミット権貰ったりするようになった
Redmine::Chan
- Redmine操作するirc botを作るモジュール
- id:onishi 作
- 2012年のYAPCのトーク聞いて懇親会後にメンテ権つけてもらった
Redis::hiredis
- 海外の人へのpull request
- 初めてXSモジュールを触る
- 結局使わなかった(後発のRedis::Fast使った)
Minilla
- 今でも立派に使える tokuhiromか作り始めた、CPANモジュールリリースツール
- 去年WEB+DB Press「今どきのモダンなCPANモジュール開発」で紹介
- 積極的に機能追加のパッチを書いた
- 自分の書いた英語のドキュメントがPerldocjpで翻訳される不思議
- QA Hackerthon Satelliteに参加
- 「車輪の再発明」ができる人たち
このへんでの学び
- 自分で頑張りすぎずCPANモジュールを使う
- OSS当たり前だけどちょいちょいバグがある
- 海外の人だからといって技術レベルが自分たちより高いわけではない(これも当たり前!)
- 英語できなくてもなんとかなる
- 躊躇なくpull request送れるように
- 車輪の再発明を恐れない
いくつかの代表作
L
- Perl extention to load module automatically in one liner
- 一文字モジュール
- コンセプトコードを書いたらtokuhiromからその日のうちにパッチが来た
- 便利だが上げるときにすごく躊躇
- IRCで相談したら、kan bayashi kazeburo karupanerura 辺りに後押ししてもらう
- なんとすぐにreviewが付く
Lで学んだこと
- 相談しよう
- ドキュメントを書こう
- reviewが好意的だったのも「Lはワンライナーのみで使ってください」って書いておいた影響も
App::RunCron
- cronを走らせる時のラッパーの仕組みを提供
- cron使いまくってたので書いた
- kazuhoさんのcronlogを参考に書いた
- めちゃくちゃ勉強になった
- パイプ経由してforkした小プロセスとプロセス間通信
- kazuho wareのソースコード読むように
- Starlet
- Parallel::Prefork
- Server::Starter
- Test::mysqld (現在メンテナ)
App::RunCronその後
- Perl Hackers Hub 「cron周りのベストプラクティス」で紹介
- 代表作にしたかったがそこそこにとどまった
- その後
horenso
で少し花開く
- 内部的にコマンド実行するツールを作るのが異常に好きになった
DBIx::Schema::DSL
create_table book => columns {
integer 'id', primary_key, auto_increment;
varchar 'name', null;
integer 'author_id', not_null;
decimal 'price', 'size' => [4,2];
add_index 'author_id_idx' => ['author_id'];
belongs_to 'author';
};
Const::Common
定数定義するやつ。参考: Const::Common探訪
package MyApp::Const;
use Const::Common (
MYAPP_BAR => 'BAZ',
MYAPP_HASH => {
HOGE => 'hoge',
},
);
1;
Plack::Middleware::Woothee
- 初めてメンテ権を譲ったモジュール
- @bayashi さん
- その後自分もメンテ権を譲り始める
Riji
- 自分Wikiとblogの中間を狙ったCMS
- 今どきの言葉だと静的ファイルジェネレーター
- git logからRSS生成するのがユニークポイント
- 自分で便利に使っている
- 僕が日本語で書いたチュートリアルを英訳してくれる人が!
- そこそこ使って頂いている
Daiku
- tokuhiromが作者
- メンテ権もらってRakeを参考にDSLを追加しまくった
- Daikufile対応がskajiさん
- version 1.0000 リリース
skajiさんとの出会い
- ご存知cpm作者
- 当時からなんか良いコード/ブログ書く人だなーと思っていた
- Gotanda.pmで声かけたり、Perl Hackers Hub寄稿してもらったり
- 結構人の発掘(?)が好きかも
- magnoliakさんもPerl Hackers Hubに書いてもらったりしました
最初は単に上げたかったから
- Math::CheckDigit
- 仕事でテストバーコードを作るためのモジュール
仕事をする上で普通に上げるようになった
- Perlで本格的にWebアプリケーションを書くと自ずと必要になった
- 使ってるモジュールにパッチを送りまくった
- CPANあげちゃおうぜおじさん業もした
上げられるものは上げてしまうように
- 社内の情報共有のためにも有用
- 社内で何度もコピペされているようなもの
- 上げてしまっても別にノウハウの流出リスクにはならない(後述)
プロジェクトコードを簡潔にするため
- モジュール側は黒魔術でもいい
- Const::Common は内部実装はちょっとカオスだけどインターフェースはきれい
気づいたメリット
他のソフトウェアエンジニアとのつながり
- 世界が広がった
- 違う組織・国の人と交流できる
- 知見を公開する人の元に知見が集まる
CPANモジュールを使う理由
- 本質であるサービス開発に集中するため
- 枯れたモジュールはやはり良く出来ている
- エッジケースのケア
- セキュリティ
- ORMとか作りたくない
- Perlは後方互換を気にする文化なので、たくさん組み合わせてもそうそう壊れない
モジュールの採用基準とオープンソース戦略
- もうひとつの知られざるオープンソース 〜 ウェブ企業のOSS戦略
- 自分がソースが読めるもの
- なるべくコントロール(協調)可能なもの
- 主体的、中心的にOSSに関わることで上手く利用する側に立てる
- Perl界はよくも悪くも日本で協調しやすい
- 独自の文化圏
- 僕にとっては良い練習場となったかも
- soozy IRC -> Slack
- とりあえずパッチを送ってみる
CPANにモジュールを上げる理由
- 自分で上げてしまえば、主体的に関わる側に立てる
- 抽象化できてHackishなコードはCPANに上げてしまう
- プロジェクトのコードベースを読みやすく、ミニマムに保つ
- 余計なリファクタループを避ける
- 社内横断的に利用する上でもCPANに上げてしまうのが最適解
- 社内モジュール化は管理コストや暗黙知の増大につながる可能性も
- 場合によっては社内モジュールと言う選択もありだとは思う
テスト駆動とオープンソース駆動
- テストを書くことを前提にプログラムを書くと設計が綺麗になる
- 同様にオープンソースにすることを前提にプログラムを書くと上手いこと抽象化できる
- 「これもうちょっと社内の事情に密結合した部分を消せばOSSにできるんじゃないか」
カルマモデル
- OSS活動していると、pull requestとかにすぐ反応してもらえるようになる
- メンテナンス権くださいって言ったらすぐもらえる
- → 開発スピードが上がる
- CPAN Authorも人間である
CPAN Authorになる方法
CPANモジュールの種類を考える
自分の得意な領域はどこか?
すごいことをやろうと考えなければできることは結構ある。
- 業界標準的なインターフェース仕様の策定
- イノベーティブなモジュール
- 多言語モジュールの移植
- 小さくてピリリと効くやつ
- 上手いこと組み合わせたやつ
- 既存の部分の隙間を埋めるやつ
- 既存のモジュールの使いやすいラッパー
- グルー
- 誰もやりたがらないやつ
- ニッチ
他の言語からの輸出入
- オススメ
- 多言語の勉強にもなる
- 僕もPerlモジュールをGoに移植したり
- RubyのモジュールをPerlに移植したり
Webサービスの非公式クライアント
- 幸い(?)Perlは公式ライブラリ提供していることが少ないので…
メンテナンスを引き継ぐ
- 僕もtypesterとかtokuhiromからメンテナンスを引き継いでいる
- GitHub止まりのやつをCPANにあげて良い?って聞く
- win-win
- 自分のソフトウェアになる責任
- メンテをすることで知識が深まる
車輪の再発明を恐れない
- 案外同じ車輪は無い
- ちょっと探して見つからないってことはあまり良くないか古い
- みんな「やりたいな」と思っててやってないことある
- そういうのやったら賞賛される
- 既存の車輪も古くなる・再発明が必要になる
良くない車輪の再発明
- 「あのモジュールよくわからないから自分が別のものをCPANに上げる」はあまり良くない
- 既存のやつを理解していないと同じ罠を絶対踏む
- 練習としての再発明としては良い
- 同様にパッチを送るのが怖いから別実装作るとかも良くない
- バグフィクスならともかく、モジュールに機能追加の要望を送るのはたしかにしりごむがissueとかで相談しよう
- 新たな知見が得られることがある(「〇〇でできるよ」「筋が悪い」とか)
- オレオレじゃなくてすでにある仕組みに「乗る」ことも大事
- コミュニティマネージメント(難しいね)
disられないためには
- 「主語の大きな」モジュール名を避ける
- 端っこでやってる分にはそんなに怒られない
- 事前に誰かに相談してもよい
- そんなに怖くない
CPAN Authorは神様か?
- 完璧な神様ではない
- ギリシャ神話の神様のような人間ぽさ
- ちょっとした間違いもある
- だから貢献できる余地はある
OSSへの貢献について
OSSへの貢献とは?
別に堅苦しくないし敷居も高くない。いくつかの段階がある。
- 使うこと「だけ」でも貢献
- 可能なら問題や疑問を報告する
- pull requestやパッチを送る
「OSSが世界を良くする」とは?
- 意識高そうで一瞬引く?
- 「世界がよくなった」としか言えないくらいの曖昧さ
- きっとどこかで何かが良くなったんだろう
- そういう世界観・価値観にベットしている
OSS界隈での協調とカルマ
- なるべく協調可能なソフトウェアを選ぶ
- カルマをためる
OSSフリーライダー問題
- 「OSSを使うだけで貢献していない」とかいう人は無視して良い
- OSSは貢献すればするほどうまく使える
- 間違った使い方を避けられる
- 互換性を崩されて突然死んだりしない
- 意思決定プロセスに関われる方が有利
現在
Mackerelプロダクトマネージャー
- 社外のエンジニアと交流した経験が生きている
- 緊張感はある
- fujiwaraさんkazeburoさんがお客様…!
- 忌憚なく意見くださるのでマジでありがたい
MackerelのOSSプロダクト
いろいろある。(主にGoとRubyですが)
MackerelのOSSプロダクト
- GitHub上では英語でやりとり
- 困ったらUser Group Slackで日本語で相談可
- OSS活動の練習場にもして欲しいと思ってます