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
390
My Recent Emacs Works
syohex
0
200
Introduction of creating Emacs Lisp Package
syohex
1
130
Emacs Introduction at LLDiver
syohex
2
3.2k
Recent Emacs Work
syohex
2
780
Introduce git-gutter.el
syohex
1
510
websocket.el and its demo applications
syohex
0
1.2k
Other Decks in Programming
See All in Programming
Webからモバイルへ Vue.js × Capacitor 活用事例
naokihaba
0
450
無関心の谷
kanayannet
0
140
Effect の双対、Coeffect
yukikurage
4
1.2k
#QiitaBash TDDでAIに設計イメージを伝える
ryosukedtomita
2
1.7k
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
860
衛星の軌道をWeb地図上に表示する
sankichi92
0
260
Use Perl as Better Shell Script
karupanerura
0
680
AIエージェントによるテストフレームワーク Arbigent
takahirom
0
360
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
10
1.6k
MLOps Japan 勉強会 #52 - 特徴量を言語を越えて一貫して管理する, 『特徴量ドリブン』な MLOps の実現への試み
taniiicom
2
640
ワイがおすすめする新潟の食 / 20250530phpconf-niigata-eve
kasacchiful
0
290
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
260
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
GitHub's CSS Performance
jonrohan
1031
460k
Typedesign – Prime Four
hannesfritz
42
2.7k
For a Future-Friendly Web
brad_frost
179
9.8k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Speed Design
sergeychernyshev
30
980
Agile that works and the tools we love
rasmusluckow
329
21k
Code Review Best Practice
trishagee
68
18k
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
ご清聴ありがとうございました