投稿日:2011年4月25日（この記事を読むのに必要な時間： 約 0分32秒）
4/27(水) 22:00〜1時間半程度 Symfonyしゃべり場 Ustreamでトーク参加します。
symfony1.4勉強会、symfony2勉強会についてや先日発売された書籍についてのトークなどを予定。
リスナーの方とコミュニケーションを取りながらトークする予定ですので、皆さんご参加ください。
チャンネルはこちら Symfonyしゃべり場 Ustream
カテゴリーアーカイブ: PHP
4/27 22時〜 Symfonyしゃべりば Ustreamでしゃべります！
PHPを使っているすべての人が知るべき無料のPaaSサービス
投稿日:2011年3月29日（この記事を読むのに必要な時間： 約 12分8秒）
symfonyをはじめ、フレームワークを稼働させるためには、ロリポップをはじめとした激安の共有サーバでは無理があります。低価格な候補としては、1年間マイクロインスタンスは無料のAmazon EC2や月額980円のさくらインターネットのVPSが手頃しょうか。しかし、まっさらなOSからの環境構築は、ハードルも高く、他の環境と混同して使うのが難しいのが実情です。
 |
日本Symfonyユーザー会￥ 2,940
|
先日発売されたsymfony本の執筆に携わらせて頂いたので、今回はPHPのPaaSホスティングサービスである cloudControl で、無料で symfony1.4 を稼働させます。きっと、cakePHPやCodeigniterも稼働させることができるのではないでしょうか。
cloudControlって？
1時間あたり1BoxというcloudControlで定義している独自の単位は無料で使えます。簡単に言うと、少ないアクセスのサイトだったら無料で使えます。それ以上のアクセスを提供するためにはunlockの手続き（有料）が別途必要です。
また、無料で提供しているアドオンが利用できます。その中にはMySQLがあるので、PHPとMySQLで稼働するフレームワークは大抵稼働するのではないでしょうか。
cloudControl で symfony1.4 を稼働させるところまで、解説することにします。
執筆した「symfony1.4によるWebアプリケーション開発」が発売されました。 #sf14book
投稿日:2011年3月23日（この記事を読むのに必要な時間： 約 1分59秒）
本日、ジュンク堂渋谷店にて
なんと！Perlの棚に並んでおります。（下の棚にはPEARの本があったので、PerlとPHPの棚なのだろうけど）
共著した「symfony1.4によるWebアプリケーション開発」が無事に発売され、店頭に並びました。
 |
日本Symfonyユーザー会￥ 2,940
|
私は、第11章のテスト駆動開発(TDD)とsymfonyによる自動テストについて執筆しました。
jenkins エレガントなコードを書くための執事のすすめ
投稿日:2011年3月9日（この記事を読むのに必要な時間： 約 0分48秒）
勉強会したので、資料公開。
jenkinsを使って、自動テストだけでなく静的コード解析や統計情報をおこなって、ケント・ベックが提唱した「コードの臭い」を察知して、リファクタリングのタイミングや具体的な指摘のフィードバックを自動で得ようというお話。
jenkins エレガントなコードを書くための執事のすすめ
View more presentations from Hiroki Ohtsuka
主に、PHPに利用できるプラグインを中心にご紹介。
これだけは伝えたい！
こういった統計の情報やフィードバックは、開発の初期段階から導入して、必ず自動化すること。問題が明らかになってから情報を収集しているようでは、判断を先延ばしにしかねない。ソフトウェア開発は短距離走ではなくマラソンです。長くエレガントに走り続けるために、初期段階から自動化しましょう。
俺とPHP
投稿日:2011年2月5日（この記事を読むのに必要な時間： 約 1分31秒）
なんか知らないうちにPHPを全然書いたことがないという噂が広まっていて心外すぎるので弁明しておく。長くなるかもしれない。
第2回Symfony2勉強会 これからの「Symfony2」の話をしよう
投稿日:2011年1月15日（この記事を読むのに必要な時間： 約 1分16秒）
達人プログラマーに学ぶ リファクタリング
投稿日:2011年1月12日（この記事を読むのに必要な時間： 約 4分25秒）
達人プログラマー 第6章 コーディング段階 p.188
ガーデニングのメタファーはソフトウェア開発の現実にかなり近いものです。あるルーチンが大きくなりすぎたり、色々なことを実現しようとしすぎている場合、2つに株分けする必要があるのです。また、計画通りうまくいかないものは雑草を抜いたり剪定してやらないといけないのです。
こういったコード記述のやり直し、再作業、再設計を総称して「リファクタリング」と呼びます。
 |
アンドリュー ハント￥ 3,990
 |
今年最初の活動はSymfony2勉強会
投稿日:2011年1月5日（この記事を読むのに必要な時間： 約 0分42秒）
本日から仕事始めでした。今年最初の活動は、以下でLTします。
既に定員オーバーですが、直前キャンセルもいくつかあると思いますのでご興味のある方は補欠登録していただければ、前日頃には定員内に入れるかもしれません。(*1)
今回はSymfony2の入門としてフレームワークのHello,World!といってもいい、CRUDを手を動かしながら学ぶワークショップとなっています。symfomy1.4を触ったこともない人もSymfony2に興味を持っているけど触ったことない人も、これを機会にSymfony2に触れてみてはいかがでしょうか。
*1: 補欠の方が多いようであれば、定員の拡張も出来るかもしれません。
達人プログラマーに学ぶ どこでも自動化
投稿日:2011年1月1日（この記事を読むのに必要な時間： 約 2分47秒）
p.235 第8章 達人のプロジェクトより
ヒント61：手作業は危険である。人間はコンピュータのように繰り返し作業が得意ではありません。それを期待することも間違っているのです。
|
アンドリュー ハント￥ 3,990
|
達人プログラマーはどうするのか？
p.240 第8章 達人のプロジェクトより
我々よりもコンピュータの方がうまくやってのけるような繰り返しや俗っぽいことは、すべてコンピュータに任せてしまいましょう。我々にはもっと重要で難しい仕事が待ち構えているのですから。
HIROCASTERの経験から
- cobblerをつかって、OSのインストールは自動化
- puppetやChefをつかって、OSの設定やアプリケーションの導入と設定を自動化
- capistranoをつかって、デプロイ作業を自動化
- Nagiosなどの監視システムやCactiなどのモニタリングシステムへの追加も自動化
こんなことはさっさとやってしまおう。物理サーバが到着したら数分で本番環境へ投入できるように。
Amazon EC2を使えば、物理サーバが到着するのも待たなくてすむ。
開発中であれば
- シェルを書いてしまって、回帰テストの自動化
- HudsonなどのCIツールを利用して結合テストやデイリービルドの自動化+ドキュメント生成や更新を同時に実行
- watchrを使ってファイルの更新があれば単体テストが自動的に走るようにすれば、TDDでテストコマンドを打たなくてすむ。(*1)
- phpmdなどのソースコード解析ツールを利用して、人のコードレビューを受ける前にバグが作り込みにくいソースが書かれているか自動チェック
開発当初から実施できていれば大きな恩恵を受けることができる。きっとシェルやcronなど使いこなせるプログラマは多いはずです。それを組み合わせれば、すばらしい自動化ツールができるでしょう。
そう。あなたには他にもっと重要なことをやる必要があるのだから。
 |
千葉 真人￥ 2,849
|
*1: IDEで同様のことを実現してもいいだろう
達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト
投稿日:2010年12月31日（この記事を読むのに必要な時間： 約 3分37秒）
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。
予期せぬバグはスケジュールに致命的な影響を与える。
手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。
 |
アンドリュー ハント￥ 3,990
|
達人プログラマーはどうするのか？
p.241 第8章 達人のプロジェクトより
早めにテスト、何度もテスト、自動でテスト
書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。
このテストをあながた手を動かしてやっている暇はありません。
あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。
自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも含めて、絶え間ない結合化と容赦ないテストを実施しましょう。チームのルールとして、バージョン管理システムにコミットする前にはテストをしましょう。
こうすることにより、できる限りバグの少ない製品コードがつくられていきます。あなたが担当する部分を「できた！」といえるときは、テストコードが存在してすべてのテストが通過しおり、仕様通りに動作していることなのです。
もう一度伝えます。絶え間ない結合化と容赦ないテストを実施しましょう。優れたプロダクトのソースコードは、製品コードよりもテストコードの方が多いのです。
HIROCASTERの経験から
テストコードは絶対に書くべき。そして、できればテストファーストでプロダクトコードを書くべき。ハッキリ言って、こういったアプローチをとらないと、スケジュールの途中で大きなバグが見つかったり、リリース後にバグが見つかったりして、バグという不具合と予期せぬスケジュールの変更と同時に戦うことになる。
そして、外野からのプレッシャーを受けてチームは疲弊していく。そして、デスマーチへ…。
このアプローチをとったチームは、スケジュールが安定する。書いたプロダクトコードには大量のテストをパスしているという保証があるので、自信を持ってデプロイやリリースができる。これは非常に精神衛生上良い。リリース日が迫って、胃を痛くする日々は無くなる。メンタルは生産性に影響する。
テストコードを書くことによって、書くソースコードの量が増えるから工数が増えるんじゃないか？
そんなことはない。
１．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッグ作業に費やします。
90%のやみくもに変更と検証を繰り返す時間がへるのだ。むしろ、生産性はあがる。プロダクトコードよりテストコードの方が量は増えていくが、テストコードは簡潔であるケースが多く、サクッと書いていける。90％の余計なことがなくなって、エレガントなプロダクトコードを生産することに集中できるのである。
あなたは今年、どれだけテストコードを書きましたか？
 |
ケント ベック￥ 3,150
 |
 |
ポール・M・デュバル￥ 3,360
 |
