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.7k
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
360
My Recent Emacs Works
syohex
0
190
Introduction of creating Emacs Lisp Package
syohex
1
120
Emacs Introduction at LLDiver
syohex
2
3.1k
Recent Emacs Work
syohex
2
770
Introduce git-gutter.el
syohex
1
490
websocket.el and its demo applications
syohex
0
1.2k
Other Decks in Programming
See All in Programming
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
4
180
UnJSで簡単に始めるCLIツール開発 / cli-tool-development-with-unjs
aoseyuu
2
290
RDBの世界をぬりかえていくモデルグラフDB〜truncus graphによるモデルファースト開発〜
jurabi
0
170
How to debug Xdebug... or any other weird bug in PHP
dunglas
1
470
ECS向けのドリフト検知機構を実装してみた
tkikuc
0
290
Go製CLIツールGatling Commanderによる負荷試験実施の自動化
okmtz
3
700
ML-прайсинг_на_Lamoda__вошли_и_вышли__приключение_на_20_минут__Слава_Цыганков.pdf
lamodatech
0
150
.NET Aspireのクラウド対応検証: Azureと他環境での実践
ymd65536
1
430
Новый уровень ML-персонализации Lamoda: Как мы усилили ее в каталоге и перенесли на другие продукты
lamodatech
0
150
Iteratorでページネーションを実現する
sonatard
3
710
文化が生産性を作る
jimpei
3
560
perl for shell, awk and sed programmers
mackee
1
690
Featured
See All Featured
Docker and Python
trallard
40
3k
Why Our Code Smells
bkeepers
PRO
334
57k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
26
4.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
105
48k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
1
290
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
31
2.3k
Documentation Writing (for coders)
carmenintech
65
4.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
39
2.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Practical Orchestrator
shlominoach
186
10k
Building Adaptive Systems
keathley
38
2.2k
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
ご清聴ありがとうございました