ログイン処理のコードレビューにおいて、認証部分が自作されていて、md5をつかっていたので、なぜ自作するのか?なぜmd5を使うのか?という点について議論になりました。

  • CodeIgniter-Ion-Authを使う
  • blowfishを使う(phpならpassword_hash関数、PASSWORD_BCRYPTオプションが良さそう)

僕は自前認証かつmd5を使う意味がわからなかったのでちょっと辛辣な表現になってしまいました。(その方が安全で楽なのに何故しないのか?的な)

ちょっと揉めてしまいまして、

「中途半端に(その実装を)採用しちゃったせいで、なんかあったら駒形さん直してくれんの?土日でも対応してくれんの?」

という感じになり、最終的には、

「レビューはあくまで"サジェスト"に留めて欲しい。」

ということになりました。コードレビューにおいて、

「ここはAAAではまずいのでBBBにすべきです。」

ではなく、

「ここはAAAよりよいBBBというやり方がありますよ。採用するかしないかは…アナタ次第です m9」

という感じですね。

https://gyazo.com/e00a80de33754a6f65c5a1c11ee15851

ホント レガシー改善は地獄だぜ

関連:レガシーPHP改善日記シリーズ

前回からだいぶ間が開いてしまいましたが進捗報告です。

Vagrant + Ansibleで開発環境作成

作りました。Windows・Macで自分のローカル上で開発できます。しかし、まだ皆さんこの環境上での開発に移行できていません。要トレーニングです。

Github利用

Github使えるようにしました。しかし前述のローカル開発環境に移行できないのでやっぱり以前のsvnでの開発が続いてしまっています。要布教・トレーニング。

自動テスト

phpunit + seleniumでテストのサンプルを作りました。しかし前述のローカル(略)

フレームワーク

次期フレームワーク選定を社内の小さなアプリ開発を通して行っています。Laravel5を試していますが良さ気です。ORM, Migration, gulp, scssとデフォルトでてんこ盛りなので最近の作法を覚えるのにちょうど良いのではないかと思います。

インフラ

現在はマネージドサーバーなのでLinuxを管理してないですが、パブリッククラウドに移行予定です。それには社内にLinuxが分かる人が(俺以外に)1人は必要なので採用を進めています。

感想

皆さん日々の業務の締め切りが当然あるので環境改善ばかりやってるわけにはいかず、なかなか進みません。gitへ移行したけど次の週にはsvnに戻ってたり。しかし少しづつですが確実に進歩しています。根気強く布教・メリット説明・トレーニングを続けていってレガシーPHP駆逐を目指します。

関連:レガシーPHP改善日記シリーズ

第89回 PHP勉強会@東京に行ってMac・Windows共通のPHP開発環境 // Speaker DeckというLTをさせていただきました。

会場は株式会社リジョブさんの咲くらぼというスペース。人工芝に座って人工桜を見ながらビール飲んで勉強会とか最高かよ。

咲くらぼ TECH 勉強会サポート | 咲くらぼTECHブログ - 株式会社リジョブ

また、じゃんけん大会でLaravelエキスパート養成読本をいただきました。ありがとうございます。

LT内容を箇条書きにまとめるとこんな感じです。

  • レガシーPHP改善はまずは共通開発サーバーの撤廃からはじめるとよい。
  • WindowsでのPHP開発環境をMac上のVirtualBox内のWindowsでサクッとできるとか思うなよ。
  • shin x blogは神。
  • ansibleはlocalで使え。
  • VirtualDocumentRoot + PHPには罠がある。
  • xip.ioを活用せよ。
  • chocolateyは神ツール。

足ばやになってしまった質疑応答に対する補足。

Q. AnsibleはWindows対応してなかったっけ?

A. provision対象としてはサポートしてるけど、clientの実行マシンとしてはサポートしてません。

Installation — Ansible Documentation

Currently Ansible can be run from any machine with Python 2.6 or 2.7 installed (Windows isn’t supported for the control machine).

Q. Windows対応してないなら何でAnsible?chef-zeroは?

A. ごもっとも。chefは個人的にキモい(ネーミングとかberkshelfとか)。私がruby好きなのでrubyで何でもできるchefをPHPの会社に導入するとやり過ぎてしまうのが怖かった(vagrantはいいのかよ > 俺)。など。後は小規模ではchef-zeroよりansibleの方がシンプルで覚えるのも簡単だと思う。

私の構成管理ツールについての苦悩のエントリーはこちら

構成管理ツールについて - komagata

Q. 技術的な内容ばかりだけど、レガシーPHP改善は「このままでいいや」というみんなのマインドセットを変えることの方が重要なのでは?何か工夫していることは?

A. おっしゃるとおり。答えは例えばみんなを誘ってPHP勉強会に来る、発表する。(3人来ていただけました。ありがとうございます!先月はボッチで行った!)

レガシーPHP改善日記 シーズン2 エピソード1 - komagata

流行りの環境うんぬんは単なる手段であり、"経営陣を含めたマインドセットの更新が大事"ってのはありますが、そんな話みんな読みたくないでしょ?

エピソード1ではこんなこと言ってますがちょっとだけ・・・。

プレスコットのピクルス原理

「漬け水がキュウリに漬かるよりは、キュウリが漬け水に 漬かるほうが早い。」これは、「長いものには巻かれろ」という 世渡り術指南の、ちょうど逆を意味する。 すなわち、大きな仕組みに影響を与えようとして、 接触を続けている小さな個(自分)は、結果として、むしろ自分のほうが変えられてしまう可能性が高い、ということを警告している。

ピクルス原理によれば私が一人息巻いて乗り込んだところでレガシーPHPシステムは変わりません。むしろこっちがレガシー寄りになる。

シーズン1からお読みの方はご存知の通り、レガシーPHP改善にとってPHPコミュニティーと会社をつなげることは既定路線であり、必須のメソッドです。

今回は内容をブログに書くということも了承を得てからお仕事を受けています。(ほう、経験が生きたな

ピクルスを漬けている瓶に穴を開ける。そしてPHPコミュニティーという大きなプールにピクルスの瓶ごと突き落とす。そして割るぐらいのことをしないとマインドセットは変わらないと思います。

逆にいえば人間はピクルス原理のように周囲の環境に急激に馴染むという性質をもっています。PHPコミュニティーという良い漬け水に浸かれば急速に周囲に馴染んでいき、良いPHPエンジニアになれると思います。(良きキュウリは別の瓶に移って行ってしまうという別の法則もありますが…)

レガシーPHP改善でうかがってはじめに取り組んだのがslackの導入です。それまでIP-Messengerやメールで密書のようなやりとりをしているところにslackを導入し、何かにつけPHP界隈の情報を流しました。

先月も今回の勉強会も1時間前まで「まだ定員に空きがあるのでお時間がある方は是非」などと「こいつウゼェ・・・」と思われても仕方ないぐらい必死の勧誘をしました。

また、今回参加された方がいたことで変化に前向きな方々=心強い味方を見つけることができました。そういった方々に協力をおねがいして、参加できない方も巻き込むために社内で開催するぐらいの勢いでやる必要があります。

今回唯一の誤算はレガシー改善はまだ途中であり、会社名は改善が成ってから公開予定だったのですが、自己紹介で「今、自己紹介されたkomagataさんと一緒にやっている(略)」と会社名が思い切りバレたことです。

そりゃあそうなるわなと思いました。何が誤算だよ > 俺

関連:レガシーPHP改善日記シリーズ

PHPでハマったことをPHPの落とし穴と題して逐次書いていきたいと思います。

問題

ログインができない!動いている環境とPHPのバージョンも合わせたのになぜ!?

$_REQUEST$_COOKIEの値が入ってないぞ。

原因

$_REQUESTの中身はphp.iniのrequest_orderディレクティブの値に依存する。デフォルトではCookieのCが含まれてない。

PHP: コア php.ini ディレクティブに関する説明 - Manual

解決策

php.iniのrequest-orderディレクティブにCを追加する?

そうではなくCookieを使いたい場合はこういった環境依存のある$_REQUESTではなく$_COOKIEを使うべき。コードの意図も伝わりやすい。

しかし、一度大量に混入したcookie用途の$_REQUEST利用を全て修正するのは難しそうだ。単純にreplaceはできないので$_REQUESTでgrepして、文脈から判断するしかなさそうだ。

明確な理由がない限り$_REQUESTはおすすめできない。$_GET, $_POST, $_COOKIEを使うべきだ。

PHPのスーパーグローバル変数($_から始まるやつ)の扱いは名前が表す通り注意が必要だと思いました。

関連:レガシーPHP改善日記シリーズ

週1日のペースで出社して作業してるんですが、なかなか手強いですね。

サイトが沢山問題

でかいレガシーシステム一個と戦うのではなく、30個ぐらいのサイトがあって、それをメンテしなきゃいけないので大変です。

システム的には殆ど同じなので、大元があってそれをコピーして使っています。コピーしたあとはそれぞれのサイトでカスタマイズが入るので分岐していきます。

これは壮大なコピペと同じことなのでメンテ対象のコード行数が増大していきます。一刻も早くこれをしないですむように設計しなおさないといけません。

共通開発環境問題

社内サーバー上に共通開発環境が一つあって、そこに上記の30近くのサイトが並んでます。そこをみんなでいじって、誰かが代表としてsvnにコミットします。

共通開発環境には、誰か一人が開発環境を作ればいいという利点がありますが、二つの問題点があります。

  1. 誰が変更したのかわからないのでレビューできない。一つ一つの変更がいい加減になり、いらないファイルが放置されて散らかりっぱなしになる。(スラム化)
  2. 複数人が同時に作業していると変更点が衝突する、壊れる。

進捗

とにかくまずはテストを書かないことには変更もできないのでテスト環境の作成を進めています。しかし、固定のパス設定などポータブルになっていないのでローカルやCircleCIで動くようにするまでが一苦労。

最近のPHPだと動かない機能を使っていたら修正。最近のMySQLだと動かない書き方を修正。結局、まずは共通開発環境と全く同じOSをVirtualBox上に用意して動作させることにしました。

これでphpunit + seleniumのテストはなんとか動きそうです。

悩んでいること

テストが動き、コードレビューを機能させるには各自が自分の環境を持つ必要があります。Windowsでは動かない機能も使っているのでVirtualBoxに環境を作ってそこで各自が上記の30超のサイトを開発しなければなりません。

VirtualBoxのSynced Folersは遅いのでWindowsの場合はsmb、Macの場合はnfsを使って・・・など、僕は構わないですが結構敷居が高くて、

「みんなホントにこれで開発してるのかな?」

と不安になってきます。

共通開発環境問題の問題点を解決しつつ、環境構築の手間を少なくする方法は何かないもんでしょうか・・・。

みんなどうしてるのか気になって仕方ないので次回のPHP勉強会東京に参加登録しました。

第88回 PHP勉強会@東京 - PHP勉強会@東京 | Doorkeeper

関連:レガシーPHP改善日記シリーズ

「FRINGE/フリンジ」の J.J. エイブラムスと「ダークナイト」の脚本家ジョナサン・ノーランが贈るわけではない、IT業界のタブーに切り込んだサスペンス実話。

(私本人は真剣にレガシーPHPに取り組んでおります。)

  1. シーズン1
    1. エピソード1
    2. エピソード2
    3. 特別編1 レガシーPHPプロジェクトあるある
    4. エピソード3
    5. 特別編2 phpプログラマーの募集
    6. エピソード4
    7. エピソード5
    8. エピソード6
    9. エピソード7
    10. エピソード8
    11. 特別編3 PHPMatsuri2012
    12. エピソードLAST
  2. シーズン2
    1. エピソード0
    2. エピソード1
    3. エピソード2
    4. エピソード3
    5. 番外編1 ピクルス原理を誤用(応用)する
    6. エピソード4
    7. エピソード5
    8. エピソード6
  3. PHPの落とし穴
    1. PHPの落とし穴1

ツール

レガシーPHP改善・コンサルティングはこちらから承っております。お気軽にどうぞ。

お問い合わせ | 合同会社フィヨルド

レガシーPHP診断を作りました。

回答結果はこちらで見られます。

レガシーPHP診断 - みんなの診断結果

基本的に選択肢の上の方がよりおすすめという感じです。まずは自社の環境がどのような状態か把握するチェックリストとして使っていただければいいかなと思いました。

改善に関してはPHP: The Right Wayが参考になると思います。

関連:レガシーPHP改善日記シリーズ

初日、行ってまいりました。

流行りの環境うんぬんは単なる手段であり、"経営陣を含めたマインドセットの更新が大事"ってのはありますが、そんな話みんな読みたくないでしょ?

僕が調べた現状と、こういう風に持って行きたいという理想の環境を書き出してみました。

現状

  • 本番環境
    • さくらのマネージドサーバー(FreeBSD)
  • ステージング環境
    • 共有開発サーバー(社内に古めのCentOS)
  • 開発環境
    • 共有開発サーバー(社内に古めのCentOS)
  • ソースコード管理
    • svn
    • 共有開発サーバーのコードを担当者一人が全員を代表してsvnにコミットする。バックアップ的な役割
  • タスク管理
    • 社内の独自タスク管理システム
  • デプロイ
    • 共有開発サーバーのソースをFTPでアップする
  • 開発マシン
    • Windows7
  • コーディング規約
    • PEAR標準コーディング規約をカスタマイズしたもの
  • コードレビュー
    • なし
  • チャット
  • ナレッジ共有
    • 社内の独自情報共有システム
    • 社内の独自日報システム
  • 自動テスト
    • なし
  • サーバー監視
    • なし
  • エラー管理
    • メールが飛ぶ
  • ライブラリ利用
    • なし
  • フレームワーク
    • なし(一部Codeigniter)

理想

  • 本番環境
    • AWS?
    • DigitalOcean?
  • ステージング環境
    • 上記サービス上に構築
  • 開発環境
    • 各自のローカルマシン
      • Vagrant?
      • Docker?
      • XAMMP?
      • 共通開発サーバーに全員分の環境を作る?
  • ソースコード管理
  • タスク管理
    • Github Issue?
    • Pivotal?
    • Trello?
    • これは現状維持でもいいかも
  • デプロイ
  • 開発マシン
    • Mac?
    • Linux?
    • Windows?
  • コーディング規約
    • PSR-4(via @tadsan さん)
    • PSR-2
  • コードレビュー
    • PRベースで行う
  • チャット
  • ナレッジ共有
    • Github Wiki?
    • これも現状維持でいいかも
  • 自動テスト
  • サーバー監視
  • エラー管理
  • ライブラリ利用
  • フレームワーク

感想

正直レガシーPHPの現場というと、"鳴り止まぬクレーム電話"、"デスマ続きで死んだ目をしたプログラマの群れ"などをイメージしてたんですが、現行のシステムでちゃんと商売が回って売上が上がっているし、現状を良くしていきたいというポジティブな雰囲気があったのでそれだけで行ける気がしました。

現行のツール類や開発フローに関しては、皆さんも思ったかもしれませんが、"懐かしい"の一語に付きます。昔は僕らだってみんなこうだったんだよ!

これはレガシーPHP(Legacy PHP)というより古き良きPHP(The good old PHP)と呼びたい感じ。

見えてきた開発環境の今昔

こうやってカテゴリ分けしてみると昔と今で同じ方向ですべてのツールが進んでるように感じます。

昔(って言い切るのはひどいですが)は社内で閉じていて外からは使えません。今のツール群はオープンでどこからでもスマホなどいろんなデバイスで使える傾向にあります。

また、昔のツールは1人または少人数で同期的に使うように出来ていますが、今のツールは多人数・非同期で作業することが前提となっています。

要は「場所・人数・時間」を選ばないように進化してきてるってことですかね。

困っていること

理想に近づけるのにまずやる必要があるのが、みんながひとつの開発環境を使っている現状から個別のローカルで開発してコミットするというフローに変更するところ。

たくさんのサイトが社内の共通開発環境で動いてるのですが、デザイナーも含めてWindowsでローカル開発に変えるには今だとどうするのが一番いいんでしょうか?

XAMPP?Vagrant?Docker?どっかのサーバーに全員分の環境を作る?

もしおすすめがあったら教えていただけるとありがたいです。

世の中のレガシーPHPを減らしたい

レガシーPHPを改善する一連のフローを毎回苦労して行うのは無駄ですよね。レガシーPHPを改善したいと思っている会社さんはたくさんあると思うし、それができる小さい会社やフリーランスのプログラマーもたくさんいると思いますし、求人・お仕事のマッチングもたくさん生まれるのではないかと思います。(前回ご一緒させていただいた @kaz_29さんや@kjirouなど僕が出会えてる人はその本当一部なので)

そこで、上手くいきそうだったらレガシーPHP改善のノウハウを共有するイベントや実際に改善していく集団・コミュニティーが出来たらいいなとおもいます。

関連:レガシーPHP改善日記シリーズ

レガシー坂は終わっていなかった。

3年前のレガシーPHP改善日記を見てレガシーPHPと開発フローの改善したいとのご依頼があったので再びレガシーPHPと格闘することになりました。

今回は皆さんWindowsをお使いとのこと。そこに若干の不安。どうなることやら・・・。

関連:レガシーPHP改善日記シリーズ

福岡で行われたPHPMatsuri2012に行って来ました。

PHPConference2012も行ってるし、訓練されたPHPerと言えそうです。

夜の闇PHPMatsuriのアン・リーダブルコード選手権にレガシーブラックが出てました。

レガシー戦隊。

「レガシーブラック、一体何者なんだ・・・。」

「全力でたけしの真似をして望んだがMr. レガシーになれなかった。プロジェクトの仲間である@hrysd, @kjirou, @kaz_29に申し訳が無い。気力も尽き、体力の限界っ!(via 千代の富士)」とはレガシーブラックの弁。

久しぶりに飛行機乗って旅行熱が高まりました。なにわともあれ、お話させて頂いた皆様、運営者の方々、お疲れ様です。ありがとうございました。

関連:レガシーPHP改善日記シリーズ