レガシーがらみで気になったのでサポートに聞いてみた。

マネージドサーバーHDDプランの契約を検討しております。

PHPのバージョンが4.4, 5.2~5.4となっていますが、これはどの5系の場合はどのバージョンになるのでしょうか?

現在PHP公式では5.4未満はサポートが行われていません。 セキュリティパッチなどは御社が独自に提供していただけるのでしょうか。

以下、サポートからの返答。

この度は弊社サービスをご検討いただき、ありがとうございます。

PHPのバージョンは4.4、5.2~5.4の中から任意にお選びいただけます。特に お客様にて設定が行われなかった場合は5.4が適用されます。

セキュリティパッチについては弊社にて独自に作成し、対応を行っております。 ご安心ください。

ご不明な点やご質問等ございましたら、本メール返信にてお問い合わせ ください。

今後ともさくらインターネットをよろしくお願いいたします。

公式のサポートが切れている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勉強会@東京に行ってきました。数年ぶり。

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

発表

Let tested using a mock with PHPUnit // Speaker Deck

phpunitは当たり前になったけどmockをもっと使おうという話。

PSR-2でLintした結果を見えるようにして、コード品質の最低限を上げる

PHP_CodeSnifferやphp-cs-fixerでPRにLint結果をコメントとして投稿する言語非依存な静的解析コマンドラッパーのSaddlerを作ったという話。

HoundCIとかはdiffのみから警告作ってるから速いのだそうです。saddlerはファイル全体を見ることで可能になるもっと詳細な静的解析を出してくれる。

Laravelの美容口コミサイトへの導入事例(スライドは未アップ)

cakephp使ってたけどlaravelで中規模サイト作ってみたらすごく良かったという話。Googleトレンドでも上昇中らしい。本ももうすぐ出るらしい。

感想

全員自己紹介のテーマが「好きなエディター」だったが、PHPStormが有料にもかかわらず圧倒的に多かった。次点でvim, sublime text2, atom, eclipseと言った感じ。(KLabでは全員にPHPStormが支給され、git clientも内蔵しているそうです。)

laravelは現状のphpフレームワークで一番良さそうに見えた。

powを別マシンから使う時に出てきたxip.ioがクッソ便利なことに今更気づいた。

% ping 192.168.0.1.xip.io
PING 192.168.0.1.xip.io (192.168.0.1): 56 data bytes

xip.ioの前にIPつけるとそのIPを返してくれる。

ってことはvagrantデフォルトの192.168.33.10を返すようにしたら便利だ。

% ping 192.168.33.10.xip.io
PING 192.168.33.10.xip.io (192.168.33.10): 56 data bytes

その前にIP以外のものを付けても同じIPを返してくれる。

% ping foo.192.168.33.10.xip.io
PING foo.192.168.33.10.xip.io (192.168.33.10): 56 data bytes

ってことは設定無しで好きなIPでVirtualDocumentRootが使えるってことだ。

Macに複数サイトに対応したPHP環境を簡単に作る - komagata

screenで絵文字が出ない問題もあってターミナルマルチプレクサを見なおしてみた。

screenで絵文字を表示できない - komagata

tmuxに移行しようかと思ったけどpaneやwindowの概念がscreenと違うし、そもそも俺は同じディレクトリでTerminalが開きたいってだけで、画面分割はvimでしか使ってないのでNew tabs open with: Same Working Directory(同じワーキングディレクトリで新規タブを開く)でいいやってことになりました。

これはMacのbash用の設定なので独自に下記の設定で、単に最後にいたディレクトリで開くようにした。

# ~/.zshrc:
function save_cwd() { pwd > ~/.cwd }
autoload -Uz add-zsh-hook
add-zsh-hook precmd save_cwd
cd `cat ~/.cwd`

vimで画面分割した時日本語がズレる問題とか、若干重い問題とかもついでに解消された。ターミナルマルチプレクサ通さない直接vimは速い気がします。

@mgikenさんにvimmer向けのやり方を教えていただきました。

参照:Vim/ファイルを暗号化する [俺の基地]

要はDropboxディレクトリ内のpasswordというテキストファイルにパスワードを書いて暗号化したいので我々vimmerにとってはvimでサクッとできるとありがたい。

$ vi ~/.vimrc
set cryptmethod=blowfish
$ vi foo
$ cat foo
VimCrypt~02!q?@?qTn&?1F_
$ vi foo

1passwordのsecure noteの動作がいまいち信用できないんでこっちで行こう。

単にテキストファイルを暗号化してDropboxのPrivateに乗せておきたい。

gpgを使うのが一般的っぽい。デフォルトではCAST5(CAST128)というアルゴリズムで暗号化されるらしい。

$ brew install gpg

暗号化。

$ echo unk > password 
$ gpg -c password
パスフレーズを入力: 
パスフレーズを再入力: 
$ cat password.gpg 
?B??ڼ?`?"?F?V?u",
                 ???B%U?$?m?3?%{In?+}??

復号化。

$ gpg password.gpg 
gpg: CAST5暗号化済みデータ
gpg: 1 個のパスフレーズで暗号化
gpg: 警告: メッセージの完全性は保護されていません
$ cat password
unk

警告が気になるが・・・。

見られたくないものはカジュアルに暗号化していきたい。

追記:

@yagi_に教えていただきました。

gnupg - How do I fix "WARNING: message was not integrity protected" when using GPG symmetrical encryption? - Super User

「AES(Advanced Encryption Standard)がもっと強力で標準の暗号化方式としてできたんだからそれを使うべきそうすべき」だそうです。

暗号化。

$ echo unk > password
$ gpg -c --cipher-algo AES256 password 
パスフレーズを入力: 
パスフレーズを再入力: 
$ cat password.gpg
?       EBr?eε?`?A?bH??<9?s?"!???2ա?W?{?>?5??H???????ř X?{?&h??`U?
                                                                  p????

復号化。

$ gpg --cipher-algo AES256 password.gpg 
gpg: AES256暗号化済みデータ
gpg: 1 個のパスフレーズで暗号化
パスフレーズを入力: 
$ cat password
unk

~/.gnupg/gpg.confcipher-algo AES256と書いておけばオプションを付ける必要がなくなります。復号時に何で暗号化されてるか表示してくれるので「何で暗号化したんだっけ?」となることがなくなってよいですね。

現時点の最新版であるRails4.2.1以下MySQLデフォルトだと絵文字が保存できません。コンシューマー向けサービスのコメント欄など今どきは普通に絵文字を入力されるのですぐに問題になります。(Incorrect string valueエラーになる)

実直な対応方法はmysqlでutf8ではなくutf8mb4を使うというものです。4byteのunicodeも保存できるようになるので絵文字も問題無しです。絵文字の種類が増えても問題無いでしょう。

ActiveRecordをutf8mb4で動かす - Qiita

穏便な解決方法

rails + mysqlデフォで動かないのと、一部のカラムでだけ対応したいこと、全テーブルのインデックスが長くなるとパフォーマンスに影響でそう、mysqlが古いと対応してない、など後ろ向きの理由があって、怖話ではDBに格納するときだけhuman friendlyな文字に変換し、出すときに戻すという実装にしました。

前向きの理由としては、画像への変換と組み合わせて怖話独自の絵文字を追加し易いという点があります。(LINEスタンプ的なのやりたかった)

実装

class Comment
  def body=(text)
    write_attribute(:body, Rumoji.encode(text))
  end
    
  def body
    text = read_attribute(:body)    
    Rumoji.decode(text) if text.present?
  end
end
mysql> select body from comments order by id desc limit 1;
+-----------------------------------------+
| body                                    |
+-----------------------------------------+
| テスト:poop::thumbsup::musical_note:    |
+-----------------------------------------+
1 row in set (0.00 sec)

rumojiはまさにそのために作られたgemでとっても簡単です。

絵文字共通化問題

非対応プラットフォームでも表示できるよう、画像に変換するというのはまた別のお話・・・。

カラー絵文字ライセンス問題 - komagata

怖話でコメント欄に絵文字を使えるようにしました。

コメントに絵文字が使えるようになりました - 怖話からのお知らせ

で、疑問に思ったのが、githubとかで画像として使われてるAppleのカラー絵文字ってライセンス大丈夫なの?ってこと。

結論としては使っちゃいけないらしい。

Emoji licensing: :cry:

しかし、Appleにメールした人によれば2014年03月12日の時点で決まったライセンスが無いらしい。

ios - License of "Apple Color Emoji.ttf" - Stack Overflow

どっちにしろ危ねえ感じです。

TwitterやGoogleなど出してるオープンソースのカラー絵文字入りフォント由来のものを使うのが安全だと思います。

ここんとこレガシーPHP改善日記がらみで仮想化技術や構成管理ツールをいじってました。(Xen、VirtualBox、Chef、Ansible、Dockerとか)

結局、"ほぼすべてを使ってみて、そして全て捨てたあとでさあどうしよう"という感じです。こんな苦労はしたくなかった。

全体的な傾向

古いものは大がかりで新しいものは無駄が少ない。

  1. 実用的な機能を備えたツールが出る
  2. パワーアップ版が出る
  3. ミニマル版が出る

イメージ方式(別名秘伝のタレ方式)とレシピ方式がある。

これはプログラム言語でいうとイメージ方式のSmalltalk vs レシピ方式のC言語みたいな構図にある。

イメージ方式は作成が楽で自由度が高い反面、分割再利用が難しい(秘伝のタレ化)。また成果物がデカイ。

レシピ方式は分割再利用が容易な反面、作成が辛い。また成果物は小さいが実行する必要があるので遅い。

現実

  • 他人のイメージ/レシピはなぜか使わない。(書き方をパクって自分のレシピに入れることはする)
  • 結局全部自分で作る/書くことになる。
  • PCセットアップ時に一回取ってくるぐらいなのでサイズどうでもいい。

結論

こと開発環境については何を選んでも苦しみはなくならない。ブッチギリの優位性もない。なので好きなの使え。(環境を導入する側が楽なツールが比較的良いですねぐらい)