ノーフレームワークレガシーPHPから始めるユニットテスト
巨大なアクセスを抱える大規模サイトは経験ないので分かりません。 あと、本当にレガシーな PHP しか考えてません。とにかくイマドキのフレームワークを使ってください。こんなこと気にする必要ないんでしょ？ 設定できるだけphp.iniに依存しないまず、PHP のコードで設定できるものは PHP のコードで設定した方がよいそうすれば複数サイトの開発のための切り替えも比較的スムーズに行えるextension など php.ini にしか書けないものは php.ini に書けばよいこれを踏まえたうえで、自分の場合はプロジェクトごとに .htaccess および php.ini を同時に生成する setup 用のスクリプトを用意している。.htaccess に書く rewrite の設定などもここで展開するようにしている。で、このスクリプトをリポジトリに入れてある。 必要に応じて RewriteBas
ノーフレームワークのレガシーPHPがCIに乗るまで
ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHP と HTML と SQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと本番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p
Capistrano は思ったよりシンプルで思ったよりすごい - あーありがち (2008-12-18)
システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な（らしい）Capistrano についてです。紹介？ いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。 Capistrano: Home システム管理の話なのになんで Puppet じゃないの？と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。 で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない？と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。 なお、例によって嘘
ようやく Rails3 アプリを一つリリースした。
リリースしたものよりもそこに至る過程や理由が自分にとって大事なのでそれを残しておこうと思う。 ※ なんかこれしか書いてないとリリースしたものがどうでもいいように聞こえるけど、そんなことないよ！ 付き合い続ける気があるからこその Rails だもの。 Rails の採用に関してオレフレームワークとの決別と人材採用のコストダウンこれまで、PHP 4.2 以降で使えるオレライブラリ、オレフレームワークで小規模なものを作ったり、PHP 3 時代からのレガシーというか遺跡級のシステムの漸進的リプレイスなどを行っていたが、どうも限界を感じていた。なんか仕事が後ろ向きな感じもしていた。このままだとずっと時代に追いつけずに終わりそうという危機感もあった。 また、Google App Engine の登場以降感じていた「うちに必要な技術はこれだよ」と具体的にはっきり言えること、それによって生み出すことのでき
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
TDD BootCamp 北陸2日目
昨日の続き。 ハヤオキクラスタ数名がご飯の前にお風呂でウダウダ。ここでもちょっと愚痴ってしまう。いかんいかん。 ブレックファストセッション朝ご飯を食べながら今日の方針をうだうだと。悩みは多いがやはりレガシーの方向に向かうことに。 ウェイクアップセッション - レガシー vs TDD デモ報告。なぜか急に腹が緩くなった。 Ioke という JavaVM 上の言語へのコマンドを Twitter から投げられる bot のレガシーコードにテストを付加し、機能追加を考えながら、手法の解説を行うという、かなり @t_wada 頼みのセッション。 検体の活きが良すぎて若干消化不良ながらも以下の解説が繰り広げられる。 まずバージョン管理、そしてブランチを切る現在の動作を Characterization Test で浮き彫りに密結合の class をぶった切る。コンパイラに怒られるかどうかでメドをつけて
TDD BootCamp 北陸1日目
※ 2日目もあります イベントに行ってきた去年の年末にあったTDD読書会＆ふりかえり（実はその日記書いてない;）からの流れも含めて、なんと！ あの！ t_wada が！ とか書いておくと follower がやってきてくれるかもしれないので名前出しを先にやってしまうけど、 3月13日 TDD Boot Camp 北陸(石川県)TDD Boot Camp 北陸についてのお知らせ - self contextsに参加してきました。トラックバックセンターは TDD Boot Camp 北陸に登壇させていただきました - t-wadaの日記 かな？ 会場白山里のウェブサイト/白山麓の自然に囲まれた天然温泉の宿、体験・研修交流館 で、分かる人は「バードハミング鳥越を越えて花ゆうゆうのもうちょい先」で分かります。ものすごい山奥を想像してたけど、地元民からすればある程度は想定の範囲内。ただし電波的にはか
北陸FxUG勉強会@石川に参加してきた
実は正式名称が未だによく分からないけど気にしない。 B-Wiki - Flex3勉強会第79回＠北陸(石川)参加受付 - Flex User Group 正直な話、Flex 方面も Android と同じくアウェイなので、実は毎回参加を躊躇していた。今回、参加を思い立ったのは実は会場の関係もあったり。というのもITビジネスプラザ武蔵でやってみたらどうだろうというのは以前から思っていたので。金沢市民的にはやはり便利な場所なんですよね、あそこは。まぁ車で行くとなると駐車場代が掛かるけど、バス 電車だと結構行きやすい。たけしまさん (mitukiii) on Twitterさんは石川高専のときに躊躇してたみたいすよ。車に乗ってると街中は面倒も増えますが、懇親会への流れやすさも考えると駅から街の辺りはやはり便利だなと感じた。で、内容。 ほぼ門外漢なりに Flash Catalyst はやはりすごい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tDiary Search
今さらRails3メモ - 番外編その2: gitに入れてないファイルの洗い出し -