現在表示しているページ
日々是作譜 » PHP系 » 第35回PHP勉強会に初参加してきました

第35回PHP勉強会に初参加してきました

8/31に第35回PHP勉強会に参加してきました。PHP勉強会の存在はなんとなーく知っていたのですが、人見知りのため恐縮して未参加でした。
とはいえ、勉強会に参加する事情があったのと、もともと興味はあったので、頑張って参加してきました。人見知りは辛いよ。

CakePHP使いはじめた人へのテクニック集公開

(私はいかにしてevents.php.gr.jpをEthnaからCakePHPにおきかえたか)

  • 発表者:haltさん
  • EthnaとCakePHPのお話
  • 発表資料
  • events.php.gr.jp
    • 現行のものは、トータル3日ぐらいでEthnaで作成
    • haltさんが働いてらっしゃるRYUSにはフリーフライデー制度という毎週金曜は仕事以外のことをする勉強タイムがあるそうで(うらやましい!)、その制度を利用して開発を行った
  • ソースコードはcodreposで公開中
  • 改善ポイント
    • いままでTypeKey認証でしかイベント参加登録できなかったものを、OpenID認証を利用してできるようにした
    • プロバイダははてなとmixiのみにサーバサイドで制限している
    • CakePHPでOpenIDを実現するために、AuthComponentを利用
    • ユーザ名とパスワードが必要なAuthComponentをユーザ名だけで利用できるように回避策を講じている(第3回CakePHP勉強会でやったらしい)
    • TypeKeyではnicknameやメールアドレスが取得できたけど、OpenIDでは拡張情報はとれる保証がないため、既存システムとの兼ね合いで、初回ログイン時に入力してもらうようにした
    • 既存ユーザがOpenIDに変更した場合には、TypeKeyのセッションとOpenIDでログインしたログイン情報を自動的に結びつけてDBに保存するようになっている
  • EthnaとCakePHPの比較
    • Ethnaでは、joinとかはSQL直書きしないといけない
    • AppModelのリレーション設定にはbindModelを使用することで容易になる
  • Q「bindModelではSQLのクエリを大量になげることになるのではないか?」
    • Ethnaは生のSQLであるが、CakePHPでは綺麗にJoinしているわけではなくて、リレーション部分ですべてSQLを投げることになる
    • でも、Web側で見るとEthnaとCakePHPで速度差はそれほどない。CakePHPでキャッシュしているからか?
    • MySQLではJOINするとテンポラリーが作られるから遅くなる。単発でうった方が軽いというベンチマークも出ているらしい

近日中にOpenID版events.php.gr.jpを公開予定だそうです。楽しみです。
個人的にはブログURLを記載する欄とかあって、参加者のブログが分かるといいなとか思ったり。

まだフレームワークを利用していないのですが(CakePHPをちょろっといじってたり、自作テキトーフレームワークだったりしてます)、EthnaとCakePHPの比較として、SQLの書き方というのは非常に興味深い視点でした。個人的にはCakePHPのbindModelは利用してみたいなと思います。
MySQLのJOINが遅くなるというのはいい情報!結構JOIN使いまくりなコード書いてました。ちょっと見直すか・・・。

自己紹介タイム

ここでですか。人見知りは辛いよ(><) 数分の発言なのに超緊張とか。
まぁ、でもこれは非常によいですね。参加者がどんな人なのかは気になるし。

PHPでもテスト駆動開発だよ

  • 発表者:株式会社ディノkunitさん
  • TDD(テスト駆動開発、Test-Driven Development)とDocTestのお話
  • 発表資料
  • PHPプロのTOM先生のテスト講座
  • テストの分類
    1. Developer Test
      開発者が行う開発促進のためのテスト
    2. Customer Testing
      顧客と機能確認のための進歩管理のためのテスト(機能、単体テスト)
    3. QA Testing
      品質保証のためのテスト(速度・セキュリティ(被機能条件)などの品質、結合テスト)
    • 2、3はテスター(専門家)がやり(プログラマーと敵対)、開発者がやるのは1で今日の話の中心。
  • 開発者は仕様書を(Excelとかで)書くのが面倒。
    • 文章ではなくコードに書く
  • TDDは三段階
    1. (きれい×動かない:花畑)
    2. RED、わざと失敗させる
      (汚い×動かない:終了)
    3. GREEN、汚くてもいい ひとまず動かす
      (汚い×動く:現実)
    4. REFACTOR、コードを洗練させる
      (きれい×動く:理想)
    • 最終目標はREFACTORだけれど、基本的にはRED、GREENの繰り返しを続けて行く。
  • DocTest
    • funcitonの直前とかのコメントに直接テストケースを書けば、テストが走る
    • 裏でPHPUnitを動かしているだけ
    • ただ、コメントがめっちゃ長くなる
    • テストが長くなる場合、メソッドを減らして責務を減らしていく方がいいかも
  • テスト駆動開発入門 ケント・ベック著
    • 「Clean code that works」動作するきれいなコード
  • Q「privateメソッドのテストは?」
    • 実際のところは課題
    • 全部がpublicにできるかというとそうではない
    • どうするかは方法論として確立されていない
    • UnitTestが進んでいるJAVAでも確立していない
    • runkitを入れるとできる
  • Q「フレームワークで使うには?」
    • In/Outを綺麗に整える
    • 外部要因がたくさんあって存在するmethodは痛い目をみている
    • ActionはテストとしてはUnitの対象ではない
    • Functional Test / Unit Test
    • ActionはRequestとResponseの汚染されている。ひとつ上がUnitTest
    • ControllerとかActionにロジックを書くな、Model側に書け。そいつ単体でテストできるようにしろ
  • Q「ユニットテストのメリット/デメリット」
    • Unitテストは、それぞれのパーツが正しく動くことしか保証できない
    • 正しいものと正しいものの組み合わせが動くとは限らない
    • もう一段階上のレイヤーのテストは必要かも
    • 何かとがっちり組み合ってしまったシステムはやりにくい
  • Q「セッション周りは?」
    • ActionとControllerがセッションをハンドリングしてくれた後の話になる。モックを作ることになる
    • 個々のものが他と影響し合わないように作っておくと容易だよねということになる
  • Q「改修案件に導入するのは困難?」
    • Railsはそこは見てない 既存にがっつりDBが組んであったらやりにくい
    • 既存の案件には導入しない方がいいかも

全然知らなかった。話を聞いた上では、確かにこれはやるべきだし、DocTestは便利かも。今度使ってみよう。

symfonyでモバイル開発なんてどうですか。

  • 発表者:ゆどうふさん
  • symfonyとモバイル開発のお話
  • 発表資料
  • キャリア/端末の違いを意識した開発が必要
    • キャリア/端末情報の取得。独自定義のHTTPヘッダーなどから取得
    • HTML/CSS
    • 文字コードのgdgd
    • 絵文字
    • セッションとCookie。Cookieが使えない機種/キャリアの存在
  • HTML/CSSの仕様
    • 全キャリアでXHMLT/CSSが利用可能
    • キャリア毎にDTD宣言を変える必要がある
    • DoCoMo
      • HTTPヘッダにapplication/xhtml+xml必須
      • i-CSS、独自仕様のインラインCSS
    • au
      • 外部CSSが利用可能、子孫セレクタなどは効かない
    • SoftBank
      • 外部CSSが利用可能、子孫セレクタもOK
    • ちゃんとデザインをしようと思ったらキャリア毎にテンプレートを作る必要がある
  • ハマリどころ
    • fontサイズの指定 サイズの変化がバラバラ
    • input要素 入力モード制御がカオス
    • mailtoの文字コード au、DoCoMoはSJIS、SoftBankのみUTF-8でURLエンコード
    • 統一テンプレートで解決するのは無理。切り替える仕組みが必要
  • 文字コードの押さえどころ
    • DoCoMoはShift_JISにすべき。UTF-8だと機種によってPOSTの際に文字が消える
    • auはShift_JISにすべき。SSL領域はUTF-8が使えない
    • SoftBankはUTF-8にすべき。Shift_JISでは機種によって絵文字がPOSTされてこない
  • symfonyでモバイル開発
    • ライブラリや拡張をうまくやっておくと、通常のWebサイトと同様の開発が可能
    • モバイルフィルタ→キャリア判定、絵文字/文字コード変換、CSSきりかえ
    • モバイル特有の処理を行うフィルタを独自追加する
      • キャリア判別:Net_UserAgent_Mobileを利用、symfonyのautoload機構
      • 絵文字変換:sfPictogramMobilePluginを利用(手前味噌)、単純にmb_conertすると失敗する可能性が高い
      • 文字コード:内部の運用コードはUTF-8で統一、入出力時にキャリア毎に表示エンコードとの相互変換を行う
      • CSS切り替え:HTML_CSS_Mobile(手前味噌)→(DoCoMoのみ)外部CSSをインライン展開
    • Cookieが使えないのは、DoCoMo全機種とSoftbankの一部機種。use_trans_sidを利用

ちょうどいまモバイルの開発をやっていて、自作gdgdフレームワーク(+Smarty)でこの辺を回避しようと思ってやっていました。でも、絵文字周りとかどうしようと悩んでいたところなので非常に有用な情報でした。
CakePHPでなんとかできないかなーと思っていたところだったんですが、Symfonyにも惹かれた。どうしよう?どのフレームワークが一番モバイル開発にはいいんでしょう?

Project ZeroでPHP part2

  • 発表者:nemo_kazさん
  • JavaとPHPの連携
  • Project Zeroの続報
    • 発表資料
    • PHPランタイムはphp.netではなくJVM上に構築
    • JAVAのGCが使える
    • PHP 5.2ベース
    • ただし、フレームワークは完全対応ではない
  • Javaクラスを利用することができる。Javaで動いているレガシーコードにPHPから軽くさわりに行ける
  • JAVAで堅く作った部分をPHPで軽く呼べる
  • MVCのMの部分をJavaにお願いしてVをPHPで作成できる
  • JavaのquolityでPHPが動く

こういうのもあるのですね。知らなかった。けど、Javaをいじったことがないので、内容はちょっと難しかったです。

まとめ

初めて参加しましたが、非常に有用でした!なんでいままで参加しなかったんだろうとちょっと後悔です。
いままで周りにぺちぱー(ていう言い方も初めて知ったよ)がいない環境でずっとやってきたので、いろいろな人のお話が聞けるというのは楽しいものですね。

運営スタッフが足りないので手伝ってほしいとのことでした。何か手伝える事があるなら手伝いたいところ。

懇談会では、ぺちぱーとPHP談義に花を咲かせて楽しかったです。後半記憶がないのですが、失礼はしてなかったでしょうか・・・。ちょっと心配。しかも電車を乗り過ごして自宅までたどり着けなかったという・・・。

いつか自分も発表できるように頑張ろう!
また参加します!

« Smartyで同一のコードを繰り返し出力をする
» iPhoneのアプリを作りたい!

Google AdSense

関連エントリー

  1. WordPressのイベント「WordCamp Tokyo 2009」4/12開催へ
  2. 10/25 CakePHPカンファレンス東京が開催

コメント投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

トラックバック

このエントリーのトラックバックURL:
http://mt.hiroyukiarai.jp/mt-tb.cgi/112

  1. 2008年12月30日 08:152008年オススメエントリ from 電脳技術者覚書
    まなめはうすさんのトラックバック企画「あなたのブログの中でおすすめのエントリを教えてください2008」に参加、トラックバックを送ってみました。...

検索

Google AdSense

カテゴリー

Blog Parts

あわせて読みたいブログパーツ
フィードメーター - 日々是作譜
track feed