最速ホムペ（PHP）案件staging環境 with Heroku

Mar 24, 2016

前提や対象者

Heroku が何か知っていてアカウントを持っていて Heroku Toolbelt インストール済みであること
Apache, Nginx, Git, PHP, Composer について普通の知識を持っていること

Heroku には Dropbox 連携の機能もあるけど、後述の応用を考えると間違いなく Git 使えて まともなコミットを作る力 をつけた方がよいです。

別に Heroku じゃなくて Bluemix でもなんでもよいです。単に自分の現在の環境ですぐ実現できるものが Heroku だっただけです。

やること

Git の準備
local の開発環境の準備
Heroku の準備

git の準備

$ git init

local の準備

composer.json

{
  "require-dev": {
    "heroku/heroku-buildpack-php": "*"
  }
}

以下のコマンドを叩いてもよい

$ composer require --dev heroku/heroku-buildpack-php

Procfile

web: vendor/bin/heroku-php-nginx

Apache より Nginx の方がよいです。サクッと立ち上げてサクッと確認。built-in サーバみたいな感じで使えるし速い。hhvm は試してないので知りません。

確認

$ heroku local

heroku の準備

アプリの追加
(buildpackの指定)
heroku git:remote -a <app>

deploy

$ git push heroku <branch:>master

deploy して動かすだけなら composer.json は空でもよいし、Heroku のドキュメントはそうなっているが、どうせ Procfile が正しく動くかどうかは確認した方がよいので、require-dev に入れておくのがオススメ。

これに慣れておくとホムペレベルじゃなくてもう少し凝った仕組みに取り組む時もだいぶやりやすい。

応用編

production が FTP でしか繋がりません: lftp と rake とか使って自動化してください。-X を上手に設定しないといろいろ漏れるので気をつけるよろし。秘密情報は dotenv 使え。
そこそこ時間が掛かったり複数人で扱う案件、あるいは継続メンテする案件です: Bitbucket -> Codeship -> Heroku とか GitHub -> CircleCI -> Heroku の連携を設定しましょう。

いちいちリンク用意しないけど Heroku, Composer, Packagist など公式ドキュメントは読みましょう。

『リファクタリング: Rubyエディション』を読んで思い出したこと

Mar 24, 2012

リンク

2000年(日本語版)の『リファクタリング―プログラムの体質改善テクニック (Object Technology Series)』から10年後の2010年(日本語版)に出た Ruby エディションを読んだ。

月末の kanazawa.js v1.7 - Back to Basics - : ATND の JSTDD Intro の準備の過程で、本当に言いたいことってなんだろう？とずっと振り返りをしていた。せっかくなので気になってた本を読んでみた。そしてようやく思い出した。自分のやりたかったことはリファクタリングだったのだと。

年代的にも日本語版で言うと

2000年リファクタリング
2003年テスト駆動開発入門

であり、Red/Green/Refactoring のサイクルはこのリファクタリングの中に出てくる。¹

コードの振る舞いを変えずに中をクリーンアップする。重複を削り、責務を明らかにする。その結果メンテナンス性が上がり、新機能の追加や変更、修正を行いやすくなる。確かに自分のやりたかったことはこれだった。

脱線してなぜ自分がリファクタリングを望んでいたのかを書いておこうと思う。

それは10年前に目の前の圧倒的にヒドいコードに打ちひしがれていたから。そこで思ったことは大きく二つ。

リファクタリングしたい（言葉は知っていた）
オレのコードもいつか捨てるしかないと思われるのではないか

それからオブジェクト指向を勉強し直したりUML描けたら設計がうまくなるかなと思って試したりしていたが、新規開発でなければやはり実際に動いているコードを相手にする力が必要だと思い知らされる。

「動いているコードをいじるな」

というのはよく言われる最もダメな姿勢の一つだが、不用意に加えた変更でシステムに致命的なダメージを与えたことも何度もある。悲しくもなったし、悔しい思いをしたし、目の前のコードを恨んだ。

ところが実際に自分の書くコードも誉められたものではなかった。今思えば、『リファクタリング』に出てくるダメな例の典型である「多すぎる引数を持った関数」も書いていた。当時の自分はオブジェクト指向は名前を知っている程度だった。オブジェクト指向の本は何冊も読んでいたが、結局のところclassを使えばオブジェクト指向だと思っているようなもんだった。

それでも諦めずに戦っていれば少しずつでも上達する。テストなんて書いたことなくたってより良いコードを目指すことはできる。でもやはり安全で確実なリファクタリングはできなかった。テストがなかったから。コードを書くことで上達はしたがコードが増えたらメンテナンス性は落ちる。

やはり自分に必要なものは確実にリファクタリングできるスキルだった。

TDDはこのリファクタリングを、特別な機会に行うものではなく毎日の開発の中に組み込む手法である²。今ならこう説明できる。リファクタリングはできればやった方がよいものではなく、毎日自然に行うもの、テストもできればやった方がよいものではなく、毎日自然に行うもの。今ならやっと言える。

テストなしにどうやってリファクタリングするの？

10年掛かったよ。もし師匠がいればもっと早くたどり着けたかもしれない。でもぼっちでも10年頑張れば少しは何かがつかめる。それは分かった。

さて最後に紹介を少々。

本書はリファクタリングそのものの紹介、リファクタリングした方がいいコードの特徴、そしてテクニックカタログである。オリジナルが出版されて10年以上経った今読むと、すでに動いているコードにも反映されてるテクニックがいくつもあったりするので、ちゃんとたくさんのコードを読んでいれば自然と気づくものも多い。それでもこれだけまとまったカタログがあると心強い。いくつかは Ruby の特徴を本当に活かしているので他のカタめの言語ではマネできないものもあるが、ほとんどのものはオブジェクト指向言語であれば適用可能だ。

動的なLLでコードを書くすべての人はお守りとして辞書として持っていていい。個人的にはデザインパターンよりも前に読むべきだと思う。具体的でかつ覚えなければいけない用語は少ない。最初から理想的なコードが書かれているわけではなく、あーあるあると思うことが多いのですんなり読めると思う。

いちばんピンときそうなのはやっぱり条件式の単純化の辺りかな。これは分かりやすくて効果がすごく大きいと思う。個人的に今回あーなるほどと思ったのはクラスアノテーションの導入から名前付き引数の流れと、恥ずかしながらやっとしっくりきたNullObjectパターン。これ使えばあちこちで .present? とか書かずに済むんだなー。

原書ではeXtreme Programming Explainedが1999年、Refactoringも1999年であり、この段階でこのサイクルは完成しているとみてよさそう。 ↩
それでいてXPほど厳格な「プロセス」ではない。 ↩

2台の AirMac Express で WDS

Mar 24, 2005

今回作った WDS ネットワークの様子

2つの有線 LAN を接続する¹ために AirMac Express を2つ使って WDS(Wireless Distribution System) で繋いだ。以下、WDS や AirMac Express の知識が不足していたためハマった点を列挙。

子ネットワークを形成する AirMac Express で Ether のポートを利用したい場合は WDS を使う必要がある
- その際は子ネットワークも固有の wireless ネットワークを作成する必要がある²
- 親ネットワークの範囲を拡張する形を採用すると Ether のポートは利用することができない
親ネットワークを形成する AirMac Express をメインステーション、子ネットワークを形成する AirMac Express をリモートステーションと呼ぶ
両 AirMac Express のチャンネルを一致させる
両 AirMac Express の作成するネットワークのパスワードを一致させる
- AirMac では WDS を利用するためには暗号化なしか WEP しか使えなかった
- AirMac Utility 4.1 以降で AirMac Express のソフトウェアを 6.1 以降に上げると WPA パーソナル（って WPA1 のことか？）で接続可能³

DHCP については、リモートステーション側で DHCP の配布をしてもメイン側のネットワークでそれを利用することはできないらしい（未テスト）。メインステーションの方で DHCP で IP アドレスを配布する必要があるという話もあるが、今回のようにメインステーションより上位で有線のルータから配る方法でも有効。

LAN 内のセキュリティを確保するために暗号化した接続で、MACアドレスを管理しておきましょう。本気でアレなら ssl も合わせて使った方がいいかな。

参考

WDS を使って複数のベースステーションからネットワークを作成する方法

製品と同梱してある印刷物にこれと同じレベルの分かりやすい情報がほしかったなぁ。。。

ついでに無線 LAN 内蔵のノートもネットワークに入る ↩
これはどうもWEPの場合の条件で、WPA2を使ったWDSの場合は逆に同一ネットワークにしないと繋がらないっぽい。明確に定義されているドキュメントが見つからないのがつらい。 ↩
てことになっているんだけど、うまくいきそうでうまくいってない。WPA の場合はチャンネルを合わせるとかえってよくないのだろうか？ ↩