Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
yapc-hokkaido-2016
Search
Syohei YOSHIDA
December 11, 2016
Programming
15
8.8k
yapc-hokkaido-2016
モジュールメンテナンスを通じて感じる最近のPerl
Syohei YOSHIDA
December 11, 2016
Tweet
Share
More Decks by Syohei YOSHIDA
See All by Syohei YOSHIDA
Dynamic Module
syohex
1
380
My Recent Emacs Works
syohex
0
190
Introduction of creating Emacs Lisp Package
syohex
1
130
Emacs Introduction at LLDiver
syohex
2
3.1k
Recent Emacs Work
syohex
2
780
Introduce git-gutter.el
syohex
1
500
websocket.el and its demo applications
syohex
0
1.2k
Other Decks in Programming
See All in Programming
フロントエンドテストの育て方
quramy
9
2.5k
Modern Angular:Renovation for Your Applications @angularDays 2025 Munich
manfredsteyer
PRO
0
130
List とは何か? / PHPerKaigi 2025
meihei3
0
550
AI Agentを利用したAndroid開発について
yuchan2215
0
210
Go1.24 go vetとtestsアナライザ
kuro_kurorrr
2
460
Scala 3 で GLSL のための c-like-for を実装してみた
exoego
1
180
RailsでCQRS/ESをやってみたきづき
suzukimar
2
1.5k
AHC 044 混合整数計画ソルバー解法
kiri8128
0
300
AIエージェントを活用したアプリ開発手法の模索
kumamotone
1
740
ミリしらMCP勉強会
watany
1
100
PHPer's Guide to Daemon Crafting Taming and Summoning
uzulla
2
1k
体得しよう!RSA暗号の原理と解読
laysakura
3
520
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
75
9.3k
GitHub's CSS Performance
jonrohan
1030
460k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Music & Morning Musume
bryan
46
6.4k
Thoughts on Productivity
jonyablonski
69
4.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Transcript
モジュールメンテナンスを通して感じる 最近の Perl YAPC::Hokkaido DeNA Co.,Ltd Shohei Yoshida
自己紹介 • @syohex • 京都の組込み企業で 8 年働いてました • 今年の 7
月から DeNA で働いています AndApp • API サーバ (Go) • Windows 向け SDK, 基盤 (C++) • OSS 活動では主にメンテナンスをしている – Emacs, Perl, Go
Perl • Mouse • Text::Xslate • Data::MessagePack, AnyEvent::MessagePack • Minilla
• plenv • Perl::Build • etc
その他 • Emacs – MELPA – markdown-mode, php-mode, coffee-mode, git-gutter,
auto-complete, popup.el, go-eldoc, emacs-jedi etc • Go – peco • zsh – zsh-completions
目次 • メンテナンスを通じて感じる最近の Perl • メンテナンスの話 – メンテナ側の話 – コントリビュータ側の話
• おわりに
最近 Perl の印象 • 一部を除き積極的には開発されていない • 新しいこともあまり行われない – 新機能開発はあまり行われず –
新しいモジュールも出ない • 古いモジュールが壊れたまま放置 – パッチ , PR が放置されることが少なくない • 反応が乏しい
モチベーションの低下 • そもそもあまり触らなくなった • Perl に革新的なことが起きない – バージョンを重ねるごとによくなっているけど – (
個人的に ) そこまで熱意を保てるものではない – 技術的チャレンジがない – それでいて壊れることが稀にある
昔 Perl を盛り上げていた人たちは • メインの使用言語が他の言語へ – Java, Scala – Go
– Ruby, Python • みんな年を取った – 自由に使える時間が減った
Perl を通じて思うこと • バリバリ開発している時期ならいいけど , それ をすぎるとメンテナンスは重荷に • 早めにメンテナンス方針を立てていれば –
タイミングとしては開発が一通り完了した時点 – 問題が溜まった後では遅い • コントリビュータの意識も重要
ここから メンテナンスの話
メンテナ側の話
検討すべきこと • 継続してメンテナンスする場合 – 負荷を減らす – 共同メンテナンス • メンテナンスをやめる
メンテナンスを継続する
負荷を減らす • issue を閉じて , Pull Request のみにする – 問題調査は骨が折れる
– issue だけの人対策 (stackoverflow へ誘導 ) • 反応がない issue, PR は閉じる – 無駄に溜まった issue, PR の数は精神的によくない • Issue/PR template は効果はそれほどでもない • 自動化できるものは自動化を
負荷を減らす • サポート対象を減らす – (Perl だと )5.8 とかいつまでサポートするんだ – 自身に問題ないけど
, 依存パッケージの minimum version 更新でテストがこける原因になったりする
対応をほどほどに • No と言おう , 断ろう – 何でも対応しようとすると自分の首を締める
共同でメンテナンスする • 一人は辛い – 辛いときは些細な PR を見るのも面倒 • 共同メンテナを見つける –
commit 権限 – パッケージリリース権限 (Perl だと comaint) • issue, PR が溜まりまくる前に !!
メンテナンスをやめる
やりすぎは身を滅ぼす • 真面目にやりすぎると燃え尽きる • 他のことにまで影響が出るのはよくない • 燃え尽きるぐらいならやめた方がいいのでは
やめるときは明示的に • 単に投げ出さない • 曖昧な状況はよくない – とりあえず github にはあるけれど •
パッチ送っても反応無し • メールを書いてみても反応無し
やめるときは明示的に • メンテナンスしないことを明記 – ( 早めに )issue, ドキュメントに書く • (
もう少し ) 余力があれば – 代替手段の提示
コントリビュータ側の話
Issue, Pull Request • メンテナは対応に時間がかかる – バグの確認・調査 , レビュー –
なるべく時間がかからなく済むよう心がける • PR は自分のコードを他人に管理してもらうこ とになりうる行為
良いレポート • バグレポート – 再現手順 , 環境の情報 • 可能な限りミニマルに –
自分が受け取った時 , 再現できて , 直せると思え るものを送ろう
良くないレポート • 動かない , 壊れてるとだけ書かれる どうしろと • この機能足したら便利なはず 本当に ?
ユースケースを提示しよう
良くないコメント • +1, I have same issue – 意味ない ,
reaction で十分 – 何かコメントするなら新情報を
Pull Request の前に • 過去の PR を調べよう • 同じことを何度も指摘させないように –
かなり萎える原因になっている印象 – あなたにとって一回目でもメンテナは同じことを数 十回言っているかもしれない • github 等だと過去のコメント数をチェック
None
Feature Request • 新機能追加 , 拡張などは積極的に提案しよう – やる気のある内しか実現 ( マージ
) できない • 時期を間違うと一生実現しないかも – バグ対応ばっかりやっているときにそういう提案が あると気持ちの切り替えになることも – ユースケースを示す – コード書く前に一度相談してみる
最後に • ソフトウェアのメンテナンスは大変 – 燃え尽きてしまうことも – 計画的なメンテナンスで負荷の軽減を – コントリビュータの意識でメンテナな負荷は下がる •
Happy maintenance
ご清聴ありがとうございました