『アウトプット』の重要性|オープンソースを公開する!

『アウトプット』の重要性|オープンソースを公開する!

プログラミングにまつわるスキルのみならず、正常な人間は常に成長したいと願うもの。
成長には「インプット」が重要です。

ただ、みなさんは自分への「インプット」だけを気にしていませんか?
自分の成長に見合ったキャリアを築くのであれば、『アウトプット』も視野に入れなければなりません。

ただ、『アウトプット』はとっても面倒。。。
しかしそうとも言ってられない『アウトプット』の重要性について、ricemanさんが非常にためになるインタビュー記事を共有してくれました。
<参照:CodeCamp『興味の幅がチームの生産性を上げる』>

『アウトプット』の重要性を知るからこそ、キャリアの形成ができる

インタビューの対象者はクックパッドのCTO、成田さん。
成田さんの経歴は異色で前職はYahoo社でバックエンドエンジニアを務めていたそう。クックパッド社に転職後はインフラエンジニアとして “縁の下の力持ち” としての役割を担い、昨年から新CTOに就任されています。
なかなか注目を集める機会のないバックエンドから、フロント・バックを統括する責任者にまで上り詰めたのは、『アウトプット』の重要性を知っていたから他なりません。

かつて、徹底的に『アウトプット』にこだわった先輩に出会って以降、成田さんも『アウトプット』を意識するようになり、しっかりと『アウトプット』しなければ、自分のキャリアにならないと感じたそうです。

今では自身の『アウトプット』もさることながら、チームメンバーが『アウトプット』できているのかを個人評価に取り入れているのだとか。
ネットで公開することにより、外部の目にさらされるものづくりを行うこと。そしてそれらがメンバーの成長に繋がるということ。確かに理にかなっています。

成田さんにとって先輩との出会いが「インプット」なのであれば、こうしてインタビューで公開してくれるのも『アウトプット』の一つですね。

ショーケース・ティービーで実践しようとしている『アウトプット』

このbitWaveもショーケース・ティービーの『アウトプット』の一つの形ですが、弊社開発チーム内でも『アウトプット』を意識した活動が始まりました。

その一つが “オープンソースの公開” です。
この社内プロジェクトを耳にした時、成田さんのインタビュー内にある一節を思い出しました。
「オープンソースのタダ乗りはしない。コミュニティへの貢献がビジネスも成長させる」

社内メンバーのみんながこのインタビュー記事を読んだかどうかは分かりませんが、こういった潮流が生まれたことは非常に喜ばしいことです。

とはいえ、このプロジェクトは社内でも初の試み。
オープンソース公開で何か不手際でもあった場合、公開したファイルがいくら素晴らしくとも、誰にも見てもらえない……なんてことがあっては一大事です。
しかし、見かけによらず慎重派である元島さんが、しれっと手順書を作成していました。
それをここに一部抜粋という形でご紹介いたします。

PHPパッケージ作成手順

<用意するもの>

「Composer」
PHPのパッケージ管理システム。作成したパッケージの管理を行い、同時にパッケージが必要とするライブラリとの依存関係も管理する。
「Packagist」
上記「Composer」のメインリポジトリとなる。「Packagist」に作成したパッケージを公開することで、パッケージ情報(compser.json)にリポジトリの指定を含めずとも、パッケージのインストールが行えるようになる。

<手順1:パッケージの準備>

<手順2:パッケージ情報を定義>

項目:Package name
説明:パッケージ名
設定形式、または設定値:ベンダー名/パッケージ名(※個人ならGitHubのアカウント。会社なら会社名等)

項目:Description
説明:パッケージの概要

項目:Author
説明:作成者
設定形式、または設定値:作成者名/メールアドレス(※作成者名とメールの間に半角スペースを入れる)

項目:Minimum Stability
説明:依存パッケージの最低限の安定バージョン(※Stableが無難)

項目:Package Type
説明:パッケージの種類
設定形式、または設定値:library、project、metapackage、composer-pluginから任意の種類を設定

項目:License
説明:ライセンス(※MIT、GPL等を設定)

項目:Define your dependencies
説明:依存パッケージがある場合はYesを設定する

項目:Search for a package
説明:依存するパッケージを設定
設定形式、または設定値:ベンダー名/パッケージ名

項目:Enter the version constraint to require
説明:依存パッケージで使用するバージョン
設定形式、または設定値:バージョン、または「@stable」、「@dev」等のStabilityフラグを設定可能

項目:Would you like to define your dev dependencies
説明:開発時に依存するパッケージを設定する

<手順3:パッケージモジュールのオートロード方法を設定>

前述で作成した「composer.json」へ「autoload」ディレクティブ

項目:”autoload”: { “psr-4”: { “名前空間プレフィクス\\”: “対応す るベースディレクトリ” } }
説明:PSR-4というルールに従いオートロードを使用する。PSR-0というルールもあるが割愛。名前空間プレフィックスが”TestPackage\\”、ベースディレクトリが”src/TestPackage/”の場合、物理ディレクトリ” src/TestPackage/”配下を”TestPackage”から始まる名前空間として使用する。また、基点となるディレクトリは複数指定することも可能である。

<手順4:comporser.jsonの妥当性をチェック>

妥当性のチェックは「composer.json」をコミットする前、tagのリリース前に実行するべき。

<手順5:オートロードファイルを生成>

「composer.json」を記述し終えたら、その設定を元にオートロードのためのファイル群を生成する。コマンドを実行すると「./vendor」ディレクトリが作成され、「./vendor」ディレクトリ配下に「autoload.php」とライブラリが生成される。

<手順6:パッケージのテスト環境を構築>

6-1:開発時のみ利用する依存パッケージへPHPUnitを追加する。

6-2:インストール

6-3:インストール結果を確認

6-4:テストを試す

6-5:テスト実行

<手順7:GitHubにリポジトリを作成>

7-1:依存ライブラリが入るvendorフォルダと、インストールしている依存ライブラリのバージョン情報を保持するcomposer.lockをGit管理から省く。

7-2:GitHubでリポジトリを作成し、プッシュする。

7-3:パッケージのバージョン情報を設定する。

7-4:開発ブランチを作成し、開発ブランチの修正をマスタブランチにマージする。
7-4-1:開発ブランチを作成し、切り替える。

7-4-2:開発ブランチでファイルを修正し、コミットする。

7-4-3:マスタブランチに開発ブランチの修正分をマージする。

7-4-4:マスタブランチにプッシュする。

7-4-5:パッケージのバージョン情報を更新する。

<手順8:パッケージをPackagistに公開>

8-1:PackagistでSubmitページを開き、Submit packageにパッケージのリポジトリURLを入力し、Checkを選択する。
8-2:作成したパッケージ名が、既に登録されているパッケージ名と重複していなければSubmitが表示されるので選択する。
8-3:以上でパッケージの公開は完了。

<手順9:GitHubとPackagistを連携する>

Gitリポジトリにプッシュした内容を、Packagistに公開したパッケージに自動反映する。
9-1:GItHubで公開したリポジトリを開き、Settingsメニューを開く。
9-2:Integrations servicesページを開き、Add serviceでPackagistを選択する。
9-3:必要な情報を入力し、Add serviceを選択する。

入力項目:User
説明:Packagistのユーザ名

入力項目:Token
説明:PackagistのAPIトークン

入力項目:Active
説明:自動更新有無

といった感じです。
元島くんがここまで作成していたのは、公開までのプロセスを共有することはもちろんのこと、配布するパッケージのライセンスについても学べるという理由で作成していた模様です。

ショーケース・ティービー初のオープンソース公開!?

そしてこの度、ショーケース・ティービーがフレームワーク用PHPを公開するに至りました。
ただし、まだベータ版です。。。
このオープンソースが正式公開された際にはその詳細、そして公開後の反響については別の機会にご案内させていただきます!
お楽しみに!!

コメント