YAPC::Asia 2012 で発表したときのスライドです。

1. CPANに恩返ししよう
*** Giving back to CPAN ***
YAPC::Asia 2012
Satoshi Azuma

2. Who?
● 東 聡志
● Satoshi Azuma
● @ytnobody
● Born in Hakodate,
Hokkaido, Japan
● Perl: about 10 years
● Linux: about 11 years
● Love motorbike!
● Love perl!

3. まさか、皆が皆
Perl Hacker じゃないよね？

4. 主な対象
専らCPANモジュールを使っている人

5. 真新しい話はありません

6. ある程度Perlを弄ってきた人なら
ほぼやっている事ばかり

7. 恩返しとは？

8. 恩返しとは
おん‐がえし〔‐がへし〕【恩返し】
［名］(スル)受けた恩に報いること。報恩。
「世話になった人に―する」
By goo国語辞書

9. なぜ恩返しするのか？

10. まず考えてほしい

11. CPANモジュールは
本当にいつも完璧か？

12. CPANモジュールは本当に
いつも完璧か
モジュールのインストール時

13. CPANモジュールは本当に
いつも完璧か
テストに失敗する

14. CPANモジュールは本当に
いつも完璧か
● CPAN Dependencies
● CPANからリンク
●
環境を指定
– 依存性一覧
– インストール成功率

15. CPANモジュールは本当に
いつも完璧か
「あまり意味は無い(ﾁｮｳ訳)」とはあるが
「テスト完全成功率(ﾁｮｳ訳)」があって、
しかもそれが100%ではない物が存在する。

16. CPANモジュールは本当に
いつも完璧か
CPANは「いつも完璧」などではないし
使う側がCPANにそれを求めるのもお門違い

17. CPANモジュールは本当に
いつも完璧か
ドキュメント通りに動作しない

18. CPANモジュールは本当に
いつも完璧か
SYNOPSISが無い

19. CPANモジュールは本当に
いつも完璧か
などなど・・・

20. CPANモジュールは
いつも完璧なんかじゃない
CPAN Authorも人の子。
過ちに気づかない事もあれば
怠惰に負けることもしばしば

21. CPANモジュールは
いつも完璧なんかじゃない
「これだからPerlは」
と切り捨てるのは簡単
だがそれはちっとも建設的ではない

22. じゃあどうする
プログラマたる者、常に建設的であれ。

23. 考え方を変えよう
ここはひとつ、こう考えてみてはどうか。

24. 考え方を変えよう
俺が困ることは
他の誰かが困るはず

25. 考え方を変えよう
普段はお世話になっているのだから
ここで恩を返しておくか

26. どんな小さなことでもいい
結果的に「恩返し」することは
他の誰か（と未来の自分）の
手助けをするということ

27. 考え方、変わった？
じゃあ、CPANに
“恩返し”
した方がいいよね？

28. 恩返しのための準備

29. E-Mail
● 様々なサービスのアカウントをとるために必須
● CPAN Author やPAUSE Adminへの*最後*のコ
ンタクト手段

30. Twitter
● メールと並び必須。
● タイムリーなやりと
りに便利。
● 不具合らしきものに
ぶち当たったときに
#perl あたりでぼやい
てると、時折ヒント
や解決策を教えても
らえたりするかも。

31. Blog
● ユースケースや問題
解決方法の共有に。
● 広く問題解決方法を
募る用途に。
● Google先生が拾って
くれるので、検索
キーワードを意図し
て記事を書くと効果
が高い。

32. Github
● 開発版のソースが置
いてあるケースが
度々ある。
● Issue(チケット)の発
行を行うためにも、
ぜひ登録しよう。

33. PAUSE
● CPAN Author になる
ためのアカウントだ
と思えば大体合って
る。
– CPANにモジュールを
登録したり、CPANRT
でIssueを登録したり
するのに使う。
– アカウントを取得する
のに外人さんとメール
のやり取りする必要が
あったりする。

34. 恩返しするための方法

35. ブログに記録を残す
● ありのままを書く
●
現象
● 処置
● 結果
●
周辺状況
– アップデート状況
– 環境

36. テストの失敗を報告する
● CPANRTやGithubに
Issueを書く。
●
タイトルを簡潔に
●
現象を明確に
● ターミナルログを貼
り付ける
●
大抵は英語。
– 中学英語でもまあそれ
なりに意味を汲んでも
らえる。英語への恐れ
が最大の敵。

37. モジュールの使い方を書く
● どこに書くか
●
ブログ
– 自分の権限で書くことができる。
– 後々POD形式にできるように考慮を。
● Github
– モジュールにPOD形式のドキュメントを追加する
– README.podを置いておくと、webページとして表示さ
れる。
● POD形式になれておく

38. 改善要望を出す
● CPANRTまたは
GithubでIssueを書く
●
改善してほしい項目
を明らかに
● できればPatchか
pullreqのほうが望ま
しい
– でもコード書けないの
なら、要望だけでも書
いておこう。
●
コードが書けないから
という理由で黙る必要
はない

39. デザインの手助けをする
● デザインの心得があ
るなら。
● ロゴ ↓このロゴ作った
● ページデザイン
●
イメージキャラ
● Hackerと呼ばれる人
たちは、意外とデザ
イン面に疎かったり
することが結構ある

40. 盃を交わす
● 勉強会(小さくてもOK)
● Hachioji.pm
● Niigata.pm
● Perl入学式
● Hokkaido.pm Casual
● Perl Beginners
– ↑主宰をやっております
● お気に入りのモジュールを宣伝してこよう
● 誰かのお気に入りモジュールを使ってみよう

41. 恩返しの次は
“恩送り”

42. Githubに
モジュールをアップする

43. CPANに
モジュールを公開する

44. これであなたも
CPANに恩返し・恩送りできるかも

45. ありがとうございました。