投稿日:2011年7月29日（この記事を読むのに必要な時間： 約 0分28秒）
PHP5.3フレームワークとして華々しくリリースされたSymfony2を筆頭にPHPのあらゆるフレームワークを比較した比較表を作り上げるプロジェクトが進行中です。
比較表はこちら
まだ、抜けている箇所がありましたら、是非埋めてください。こうして一覧としてみると、いろいろと気づかされるものがありますね。
カテゴリーアーカイブ: symfony
やっとリリースされたSymfony2もおさえた、最新PHPフレームワーク比較表
プレゼンの2枚目の写真が重要なイベント第4回Symfony2勉強会を開催しました。 #Symfony2study
投稿日:2011年6月5日（この記事を読むのに必要な時間： 約 9分25秒）
第4回Symfony2勉強会に参加します。
投稿日:2011年5月25日（この記事を読むのに必要な時間： 約 1分9秒）
日本Symfonyユーザー会の方でアナウンスされている第4回Symfony2勉強会にスタッフで参加します。
当日は赤スタッフポロシャツを着ています！
既に参加者多数ですが、直前でのキャンセルなどがあると思いますので、参加したい方は補欠登録をして、前日に最終的な確認をしてみてください。
βリリースがされたSymfony2の基礎をあらてめておこなって、実践編から設計や思想に近い話も聞けるはずです。
→ «第4回Symfony2勉強会に参加します。»" class="more-link">続きを読む «第4回Symfony2勉強会に参加します。»
4/27 22時〜 Symfonyしゃべりば Ustreamでしゃべります！
投稿日:2011年4月25日（この記事を読むのに必要な時間： 約 0分32秒）
4/27(水) 22:00〜1時間半程度 Symfonyしゃべり場 Ustreamでトーク参加します。
symfony1.4勉強会、symfony2勉強会についてや先日発売された書籍についてのトークなどを予定。
リスナーの方とコミュニケーションを取りながらトークする予定ですので、皆さんご参加ください。
チャンネルはこちら Symfonyしゃべり場 Ustream
執筆した「symfony1.4によるWebアプリケーション開発」が発売されました。 #sf14book
投稿日:2011年3月23日（この記事を読むのに必要な時間： 約 1分59秒）
本日、ジュンク堂渋谷店にて
なんと！Perlの棚に並んでおります。（下の棚にはPEARの本があったので、PerlとPHPの棚なのだろうけど）
共著した「symfony1.4によるWebアプリケーション開発」が無事に発売され、店頭に並びました。
 |
日本Symfonyユーザー会￥ 2,940
|
私は、第11章のテスト駆動開発(TDD)とsymfonyによる自動テストについて執筆しました。
第2回Symfony2勉強会 これからの「Symfony2」の話をしよう
投稿日:2011年1月15日（この記事を読むのに必要な時間： 約 1分16秒）
今年最初の活動はSymfony2勉強会
投稿日:2011年1月5日（この記事を読むのに必要な時間： 約 0分42秒）
本日から仕事始めでした。今年最初の活動は、以下でLTします。
既に定員オーバーですが、直前キャンセルもいくつかあると思いますのでご興味のある方は補欠登録していただければ、前日頃には定員内に入れるかもしれません。(*1)
今回はSymfony2の入門としてフレームワークのHello,World!といってもいい、CRUDを手を動かしながら学ぶワークショップとなっています。symfomy1.4を触ったこともない人もSymfony2に興味を持っているけど触ったことない人も、これを機会にSymfony2に触れてみてはいかがでしょうか。
*1: 補欠の方が多いようであれば、定員の拡張も出来るかもしれません。
達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト
投稿日:2010年12月31日（この記事を読むのに必要な時間： 約 3分37秒）
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。
予期せぬバグはスケジュールに致命的な影響を与える。
手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。
 |
アンドリュー ハント￥ 3,990
 |
達人プログラマーはどうするのか？
p.241 第8章 達人のプロジェクトより
早めにテスト、何度もテスト、自動でテスト
書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。
このテストをあながた手を動かしてやっている暇はありません。
あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。
自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも含めて、絶え間ない結合化と容赦ないテストを実施しましょう。チームのルールとして、バージョン管理システムにコミットする前にはテストをしましょう。
こうすることにより、できる限りバグの少ない製品コードがつくられていきます。あなたが担当する部分を「できた！」といえるときは、テストコードが存在してすべてのテストが通過しおり、仕様通りに動作していることなのです。
もう一度伝えます。絶え間ない結合化と容赦ないテストを実施しましょう。優れたプロダクトのソースコードは、製品コードよりもテストコードの方が多いのです。
HIROCASTERの経験から
テストコードは絶対に書くべき。そして、できればテストファーストでプロダクトコードを書くべき。ハッキリ言って、こういったアプローチをとらないと、スケジュールの途中で大きなバグが見つかったり、リリース後にバグが見つかったりして、バグという不具合と予期せぬスケジュールの変更と同時に戦うことになる。
そして、外野からのプレッシャーを受けてチームは疲弊していく。そして、デスマーチへ…。
このアプローチをとったチームは、スケジュールが安定する。書いたプロダクトコードには大量のテストをパスしているという保証があるので、自信を持ってデプロイやリリースができる。これは非常に精神衛生上良い。リリース日が迫って、胃を痛くする日々は無くなる。メンタルは生産性に影響する。
テストコードを書くことによって、書くソースコードの量が増えるから工数が増えるんじゃないか？
そんなことはない。
１．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッグ作業に費やします。
90%のやみくもに変更と検証を繰り返す時間がへるのだ。むしろ、生産性はあがる。プロダクトコードよりテストコードの方が量は増えていくが、テストコードは簡潔であるケースが多く、サクッと書いていける。90％の余計なことがなくなって、エレガントなプロダクトコードを生産することに集中できるのである。
あなたは今年、どれだけテストコードを書きましたか？
 |
ケント ベック￥ 3,150
 |
 |
ポール・M・デュバル￥ 3,360
 |
Symfony2 sandboxコミッターになった瞬間
投稿日:2010年12月16日（この記事を読むのに必要な時間： 約 0分7秒）
PHP Matsuri 2010 ふりかえる
投稿日:2010年10月3日（この記事を読むのに必要な時間： 約 0分43秒）
今回のPHP Matsuriを象徴している写真。とってもいいですねー。
そしてこれが、JIREI NIGHTでしゃべったときの写真。
最多投票もらったときに写真撮影してもらったけど、誰か写真ください。
大事なことなので忘れないうちに、振り返りしておく。
今回良かったこと
- 発表した
- TDDのワークショップを主催した
感じたこと
- 何をHackしたいんだ。ってことを常に考えてない。
- Nateの隣に座っていたので観察していたら、ずっとコード書いてた。それが自分との致命的な差である。
今後やっておくべきこと
- BDD
- TDD Boot Camp
- 何かHackできる（したい）ものをみつけること
スタッフの皆様ありがとうございました!!