レガシーなperlのweb開発から少しだけ今風なperlのweb開発へ。継続可能な開発へ。
もしあなたが「これは是非YAPCで見たい!」と思ったら、ソーシャルメディアボタンを押して応援してみてください。選考の際に参考にさせていただきます
Tweetトーク概要
最大8年前から動き続けているwebサービス群を弊社ではメンテナンスしてきましたが、いろんな意味でこのままでは開発が困難な感じになりつつありました。
一例を挙げると、全てのプロジェクトが共通のPerlモジュールで動いていています。そのため、1つのプロジェクトでバージョン上げたいと思っても全てのプロジェクトで検証しないといけないため、自然とモジュールのバージョンアップが億劫になり、なかなかバージョンアップしにくくなっていく悪循環がありました。 他にもいろいろ問題がありこれはどげんかせんといかんということで、しがらみのない新規なプロジェクトに関しては、Plack/PSGI + Cartonな感じのわりかし今風のアーキテクチャに移行しました。
今回、既存の古めのプロジェクトでも継続可能な開発ができるようにするためのサービス基盤差し替えの作業についてお話しします。 (2015/06現在。YAPCが開催される頃には、全部切り替わってるはず!) ここで言うサービス基盤とは、PerlのWebアプリケーションを動かすためのアプリケーションサーバ、モジュール管理、実行Perlなどです。 ここでの作業ではアプリケーションコードの変更はアーキテクチャ変更にともなうもの以外はあまり書き換えてないです。
ざっくり言うとこんな感じで変えています。
昔
- Sledge
- mod_perl
- system perl
- debパッケージによるPerlモジュール管理
今(未来)
- Sledge PSGI対応
- Server::Starter + Starlet
- xbuild (Perl::Build)
- cpanfileとcartonによるPerlモジュール管理
- darkpanによる社内モジュール管理
この仕組みに切り替えるにあたって、考えたこと、はまったこと、なやんだことなど、以下の内容で話すことを考えています。
- 現状の仕組みを詳しく話しつつ、何故基盤を変更するに至ったのか
- 切り替えるにあたってはまったこと
- euc-jp
- 環境変数と言う名のグローバル変数
- 社内モジュール
- CPANに上がってないモジュール/配布元リンク切れしてるモジュール
- CPANモジュールへの社内パッチとか
- 古すぎる依存モジュール
- そこまでやるならなんでもっとラジカルに変更しなかったのか
- 理想と現実と妥協と売り上げと会社組織
- 私が考える継続可能な開発とは何か
トーク詳細
会場 | TBD |
---|---|
開始時間 | TBD |
カテゴリ | アプリケーション |
言語 | 日本語 |
同時通訳 | NO |
スライド字幕 | 日本語 |
時間 | 30 分 |
想定観客層 | レギュラー |
写真撮影 | 有り |
録画配信 | 有り |