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
370
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
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
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
370
プログラミング言語学習のススメ / why-do-i-learn-programming-language
yashi8484
0
140
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
50
17k
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
12
4.2k
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
550
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
定理証明プラットフォーム lapisla.net
abap34
1
1.8k
富山発の個人開発サービスで日本中の学校の業務を改善した話
krpk1900
5
390
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
120
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
800
Domain-Driven Transformation
hschwentner
2
1.9k
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
410
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
960
Building an army of robots
kneath
303
45k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
The Cult of Friendly URLs
andyhume
78
6.2k
Optimizing for Happiness
mojombo
376
70k
Bash Introduction
62gerente
611
210k
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
ご清聴ありがとうございました