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
400
My Recent Emacs Works
syohex
0
200
Introduction of creating Emacs Lisp Package
syohex
1
140
Emacs Introduction at LLDiver
syohex
2
3.2k
Recent Emacs Work
syohex
2
790
Introduce git-gutter.el
syohex
1
520
websocket.el and its demo applications
syohex
0
1.2k
Other Decks in Programming
See All in Programming
基礎から学ぶ大画面対応(Learning Large-Screen Support from the Ground Up)
tomoya0x00
0
330
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
590
はじめてのMaterial3 Expressive
ym223
2
160
サーバーサイドのビルド時間87倍高速化
plaidtech
PRO
0
720
Ruby Parser progress report 2025
yui_knk
1
350
ソフトウェアテスト徹底指南書の紹介
goyoki
1
150
速いWebフレームワークを作る
yusukebe
5
1.7k
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.5k
もうちょっといいRubyプロファイラを作りたい (2025)
osyoyu
0
350
私の後悔をAWS DMSで解決した話
hiramax
4
200
Protocol Buffersの型を超えて拡張性を得る / Beyond Protocol Buffers Types Achieving Extensibility
linyows
0
110
250830 IaCの選定~AWS SAMのLambdaをECSに乗り換えたときの備忘録~
east_takumi
0
380
Featured
See All Featured
Making Projects Easy
brettharned
117
6.4k
How to train your dragon (web standard)
notwaldorf
96
6.2k
RailsConf 2023
tenderlove
30
1.2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
187
54k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
A designer walks into a library…
pauljervisheath
207
24k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Statistics for Hackers
jakevdp
799
220k
A better future with KSS
kneath
239
17k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
We Have a Design System, Now What?
morganepeng
53
7.8k
Side Projects
sachag
455
43k
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
ご清聴ありがとうございました