スポンサーサイト

0

    一定期間更新がないため広告を表示しています


    • 2014.12.23 Tuesday
    • -
    • -
    • -
    • -
    • -
    • by スポンサードリンク

    Symfony2 Certification不合格体験記。

    0
      この記事はSymfony advent calendar 201423日目の記事です。
      前日は @polidogさんでした。
       

      Symfony Certificationとは?


      Symfonyの開発元であるSensiolabsが実施しているSymfony開発者の資格試験です。
      https://sensiolabs.com/en/symfony/certification.html
      ・CBTで全問選択式(記述問題は無し)
      ・75問
      ・試験時間90分
      ・試験範囲は16のテーマから
      ・合格基準は非公開
      ・最初はヨーロッパまで行かないと受験できない仕組みでしたが、2013年10月から日本各地のピアソン試験センターでいつでも受験できるようになりました(近所のピアソン試験センターはここから検索できます)
      ・階級が2種類あり、試験に合格するとどちらかに認定されます
      ・試験に落ちても1年に2回まで再受験可能
      ・受験料250ユーロ。日本円に換算して約3万6千円(2014/12/23現在のレート1ユーロ=146.11円で計算)…高っ!w

      まぁ日本で受験した人は少ない(下手するといない)んじゃないかという試験です。
      # 合格しても日本では特にメリットが見いだせないですし…^^;
       

      受験のきっかけ


      2014年10月、Symfony 9周年を記念して発表されたTOP150 contributorへの受験バウチャー(高い受験料がタダになるチケット)プレゼントの該当者になったからです。
      ちなみにsymfony/symfonyとsymfony/symfony-docs両方でランクイン(symfony/symfonysymfony/symfony-docs)したんですが、貰えたバウチャーは1枚だけでした。チッ、ケチだな!
      SensioLabsのサイト上で情報を登録してから、メールの指示通りにピアソンVUEにデータ連携して登録すると準備完了です。ちなみに、日本でもポピュラーな資格試験なら日本語UIで登録が出来るようですが、マイナーなSymfonyは全て英語UIでした…。
       

      受験勉強


      この辺りを読んだり
      https://github.com/jmolivas/symfony-certification-guide
      http://www.craftitonline.com/2014/05/the-symfony2-exam-drill-unofficial/
      certificationyという(非公式の)コマンドライン学習ツールを使ったりして勉強しました。
      特にcertificationyは全部で136問の問題から20問ずつ出題され、オフラインでもできるので、暇つぶし(昼休みとか電車移動中とか)にちょこちょこやっているとほぼ全問正解できるところまでやりました。(が、後述するようにそれほど効果なかった模様…orz)
       

      試験の予約


      ピアソンVUEのサイト上で希望するテストセンターの空きを確認し、予約を入れます。
      ※今回タダ券として発行されたバウチャーコードはこの予約の最終段階でようやく使いました。

      私の場合は、アドベントカレンダーに書くために受験を決意したのでw 受験し終わって心の整理が間に合うように12/18にしました。
      (首都圏は大丈夫かもしれませんが)テストセンターによっては平日は夜しかやってなかったり、土日が原則休みだったりと結構枠が狭いので早めに予約を入れたほうが良いです。予約は48時間前までなら無料で変更できるとのこと。
       

      受験


      当日は名古屋市内も9年ぶりの大雪だった日で、「小学校が休校になったらどうしよう」とか「電車が止まって試験センターまで行けなかったらどうしよう」とか不安だったのですが、休校せず電車の遅れもそれほどなく受験自体は無事にできました。
      荷物を預けて指定されたパソコンの前に座って、チュートリアルを読み終わったら試験スタートです。90分間と設定されていますが、早く解き終わってもう直す必要なしになったら時間終了前でも終わりにできます。(90分まるまる座っていると小学校の下校時間までギリギリだったので助かりました)
      試験後はその場ですぐに結果通知を貰えます。
       

      結果


      落ちました(´・ω・`)
      合格基準非公開とあって、私の実際の得点が何点だったとか、あと何点足りなかったといった情報はありません。ただ "Fail" のみ。
      覚えている範囲で答え合わせをしてみると、もともと不安だった認証・キャッシュ周りで間違えたのと、デフォルトのコマンド関係で落とした、と思います(自信なし)
      これから受験を検討する方は、certificationyで出てくるマニアック問題(ほげほげコンポーネントにはクラスがいくつだとか、Symfonyには全部でいくつのコンポーネントがあるとか、twigの使い方とか、個別のコンポーネントのメソッドシグネチャがどうとか)を覚えるよりも、基本的なSymfonyの使い方とHTTP知識を磨いたほうが良さそうです。特に、細かく設定したり実装したりする機会の少ない(1つのプロジェクト内で何回も使うことはまれな)認証関係は基礎知識をよく確認しておいた方が良いでしょう。
      なお、当然のことながら試験の説明・問題文・選択肢すべて英語なので、問題文で何を訊かれているか・各選択肢がどういう意味かを辞書なしで読む程度の英語力は必要です。といっても未翻訳のドキュメントを英語版で読んで(厳密な翻訳でなく)なんとなく意味がわかれば大体それで十分だと思います。
       

      まとめ


      受験料が高く、受かっても特にメリットが無いので自腹で受けるのはちょっと…な試験ですが、もし再度の機会があれば今度こそ知識のあやふやなところをしっかり勉強して臨みたいです。おしまい。


      「わりびき」の解説 #Scratch Advent Calendar 2014 day 7

      0
        Scratch Advent Calendar 2014 7日目の記事です。
        前の日はうちの小4による「"わりびき"をつくりました」 でした。
        次の日は募集中です。誰か書きませんか?

        「わりびき」が誕生したきっかけは、Nagoya.php vol7でした。
        ※Nagoya.phpは名古屋でだいたい隔月開催しているPHPの勉強会です。勉強会ですが、LTや発表にはそれほど重点はありません。プログラム問題を課題に皆で黙々と時にわいわいとPHPのコードを書いている勉強会です。

        Nagoya.php vol7で選ばれた課題が偶々再帰を使う問題で、さらに偶々PHP初心者(プログラミング初心者も含む)が多い回だったため、終了後に常連の間で「再帰はプログラミング初心者にはハードル高い」「再帰を理解できるかどうかがプログラマ思考の分かれ目では?」という話になりました。
         
        そこで、「プログラミング初心者(といってもScratchを使ってすでに2年近く経とうとしているんですが)のうちの子供に再帰を使わせてみよう!」という話になったわけです。
        が、ハノイの塔は難しすぎる気がして(なにせ私自身イメージが湧かない)何か他に良いネタはないかと考えていたら、子供自身から何気なくネタが提供されました。
        「もし割引券を何枚でも使えたら、いくらでも安くできる?いくらまで安くできる?すっごく高いものがタダで買えたりする?」

        そのネタが飛んできたのが外出中だったこともあり、口頭で100円を10%オフ券でいくらまで安くできるかをやってみただけで終了。
        「ところで、いま割引券何枚使った?」
        「忘れた」
        「よし、後でscratchでやろうね」
        という感じでScratchで組んでみることになりました。

        そんなわけで、うちの子が作ったのが「わりびき」です。

        http://scratch.mit.edu/projects/37549232/

        「中を見る」を見れば分かる通り、再帰になりませんでした(汗
        私が誘導することなく、子供がわからないと言った概念や計算方法(パーセントの概念とか、10%オフの計算の仕方とか、切り捨て・切り上げとか)だけ説明しつつ、子ども自身に好きに書かせたら「〜まで繰り返す」だけで解決してしまったのです。

        そこで、私が自分で再帰版を作ることにしました。(ここまで前置き。長っ!w)

        http://scratch.mit.edu/projects/37977098/

        うちの子供はScratch1.4で育てたので、「ブロックを作る」という発想があまりなかったようで、それが敗因(?)だと思います。
        さっそくこれを書いている私の後ろから覗き込んで「再帰ってなに?」とか言ってるので、私の作った再帰版を見せながら説明して理解できるか見てみたいと思います。

        最後に宣伝です。
        こんな親子が運営するCoderDojo Nagoyaは第3回は12/14(日)開催です!
        http://coderdojo-nagoya.doorkeeper.jp/events
        今回はScratchではなくHour of Codeをやりますが、普段は初心者にはScratch cardの作例・上級者には好きな作品を作ってもらい、最後に発表するという形式でやっています。
        名古屋周辺で興味のある方は来てみてください。メンター希望のプログラマも歓迎です!


        Doctrineでファイルアップロードを扱う方法 がイケてない件 #symfony_ja

        0
          ユーザーにファイルをアップロードさせてサーバー側に保存する。非常によくある処理です。
          公式のSymfony cookbookには既にそのものズバリなタイトルのドキュメントがあります。

          How to Handle File Uploads with Doctrine
          http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html
          日本語訳:Doctrine でファイルアップロードを扱う方法
          http://docs.symfony.gr.jp/symfony2/cookbook/doctrine/file_uploads.html

          日本語版は原文に比べて多少内容が古いですが、説明されている実装方法は同じです。
          最近、Symfony歴の浅いプログラマにSymfonyの使い方を説明する機会がなぜか多く、そのうち一人にファイルアップロードのケースを書いてもらおうと思ったのですが、上記ページを見せて説明していたら心中「なんか違う…」という違和感がフツフツと湧いてきたのです。

          まだまだsymfony1癖が抜けずSymfony2初心者だった頃の私にとっては「素晴らしい!」と思えたのに、なんでだろう?
          というわけで、どこが違和感(不便…メンテしづらい…もやもや…)なのか、今の私が同じ処理を書くとしたらどうなるか考えてみました。

          まず、公式の「Doctrine でファイルアップロードを扱う方法」がイケてないと思う点は、下記の2点です。(あくまで個人的に、です。)
          1. Doctrine2のLifecycleCallback(PrePersist, PreUpdate, PreRemove)を利用しているため、実際の処理(アップロードファイルが一時保存先から恒久的な保存先に移動)がいつ呼ばれるのかわかりにくい。

          2. アップロード先パスがEntityにベタ書きでテスト/変更しづらい。
          アップロード先のディレクトリ(Document::getUploadRootDir())を直接書かざるを得ません。特にサンプルコードのように__DIR__を使って書かれていると、Symfony2 standard editionの中に置いた状態(あるいは同じディレクトリ構造を無理やり作る)じゃないとテストが失敗してしまいます。せっかく再利用可能なバンドルを書いても単独でテストできないことになります。
          それに、ファイルの保存先を設定ファイルで指定することもできなくなります。一見、Document::setUploadRootDir()のようなメソッドと$uploadRootDirプロパティを設定すればいいじゃん、と思うかもしれません。でも、そうすると「エンティティのupload()メソッドを呼ぶ前には必ずsetUploadRootDir()を呼ばなければならない」という決まりが必要になるわけです。データ保存のタイミングで必ず呼ばれるDoctrineのLifecycleCallbackを使う意味が失われてしまいます(せっかくアプリケーション内のどこから$documentを保存してもファイルアップロード周りの処理が行われるようになっているのに、アプリケーション内のどこでも$documentを保存しようとしたらまず先にsetUploadRootDir()を呼ぶ必要が出てくる)。
          #こういう実装ルールって、後々うっかりミスでトラブルになる臭いがしませんか?

          では、「Doctrineでファイルアップロード」をどう実装するか?
          答え:専用のサービスを作りましょう

          アップロードしたファイルの扱いで何が一番面倒かと考えたとき、データベース上のレコードとファイルシステム上のファイルの同期ですよね。ファイル保存したのにレコード保存してない、とか。レコード削除したのにファイル削除してない、とか。
          それ「だけ」を担当するサービスを作ってしまえば、同期の心配はそこにお任せできるわけです。

          サービスで実装した版がこちら

          実際のアップロードファイル移動処理はサービスで行い、コントローラーからはサービスのメソッドを呼び出すだけです。
          ファイルの恒久的保存先が新規Documentの保存後じゃないと決まらない場合(例えば、auto_increment/serialなidを使って保存先ディレクトリを決定する場合。id=1のdocumentのファイルをuploads/documents/1/hoge.jpgやuploads/documents/1.jpgのように保存したいとき)も、処理の順番を書き換えればいいだけです。なんならpersist()→flush()→ファイル移動処理→パス(保存されたファイル名)を変更flush()と2回保存もできちゃいます。LifecycleCallbackのトリッキーな使い方をググる必要はありませんw
          見るからにテストも書きやすいです。
          #そもそも昨今、アップロードしたファイルの恒久的保存先が同じファイルシステム内とも限らない訳で、追加要件が出てきたときにサクッと変更できるのは圧倒的にサービス方式だと思います。

          まぁこれが正解とか公式が間違っているというわけではなく、こういう方法もあるよ(こっちのほうが私はしっくりくるよ)という話でした。


          Nagoya.php vol6 に行ってきました #nagoyaphp

          0
            お盆最終日の8/17の午後、Nagoya.php vol6 へ行ってきました。

            今回は、現在の勤務先であるカルテットコミュニケーションズが会場を提供していました。
            いつものオフィスに開発部員よりも大勢のPHPerが集まってわいわいしてる光景は、なかなかレアだったと思います!

            自己紹介が終わった後は早速、後藤さんから問題が提示されます。
            今回の問題は「レッスンは何曜日? 〜 横へな 2014.5.9 問題」でした。
            Nagoya.phpに来たことが無い方のために補足しておくと、Nagoya.phpではフレームワークや画面を想定しない生PHPでプログラムを書く時間が恒例となっています。チーム戦ではなく個人戦(各自一人で取り組み)ですが、特に勝敗はつけないので、書き終わった人に質問したり、逆に困ってる人を助けたりするのは大いにありです。(私は今回、解くのにいっぱいいっぱいで助ける側には廻れませんでしたが…) 大抵は雑談しながら書くので、IDEのオススメやら実装のコツがぽろぽろ拾える時間でもあります。

            私の書いたもの
            https://github.com/77web/Nagoya.php-vol6

            コミット履歴に沿って振り返ると、下記のような感じでした。珍しく(?)、中からアプローチでなく外からアプローチです。

            * PHP.Skeletonをcreate-project
            * プロジェクト名Nagoya.Phpでcreate-projectしたらnamespaceがNagoya¥Nagoyaになってたのを修正
            * 入力値のパース→実処理→出力値のフォーマット という流れと処理に必要なデータクラスを考え、メイン処理の流れとテストをコメントアウトした状態で作成 ここで申し込み順保持の考慮漏れがあったばかりに後で苦労する羽目に…
            * 入力値のパースを行うクラスを作成
            * 実処理のクラスを作成(定員は考えず第一希望ごとに割り振るだけ)
            * 出力のフォーマットを行うクラスを作成 この時点でテストケース1,2辺りは通るようになった

            ここからは実際に出題者に与えられたテストケースの実行結果を見ながら仕様の不足点を埋めていくことにします。

            * テストケース3で出力フォーマットの「社員番号昇順」が抜けてたのに気付き、実装
            * テストケース6で実処理に「定員オーバーしたら受講できない」を実装 この時点で希望順→応募順にできたつもりでしたが…
            * テストケース11で実処理に「より希望順の高い人が後から来たら追い出される」を実装 希望順→応募順にはなった

            ここからは現場で解決できず、自宅に帰ってから追加で書いた分です。

            * テストケース18で実処理の「同じ希望順なら応募順の早い人」判定を修正 同じ希望順の時に応募順が前の人を追い出してしまっていたのを修正
            * テストケース17で実処理の追い出された後の再アサイン時に応募順がわからなくなっていた問題を修正 社員データクラスに応募順を保持していなかったので、一度アサインされて希望順で追い出された場合に応募順がわからなくなり、正しく希望順→応募順になっていなかったのを修正。応募順まで入ってくるとそれは既に社員情報(Staff)じゃないので申込み情報(Entry)にデータクラス名も変更しました。

            予定では一時間程度の予定でしたが、私も含めて苦戦した人が多かったせいか大幅に伸びて二時間になりました。
            というか、うーんうーんと頭を捻ってるうちにうっかり予定の時間が過ぎていましたw

            他の方のコード(わかってる分のみ)

            * @hidenorigotoさん
            * @ounziwさん
            * @qckanemotoさん

            似ているようで少し違ったりして面白いですね!


            結局、LT予定だった時間まで問題を解く時間に使ってしまったので、全員が懇親会参加希望ということもありLTは懇親会で行うことになりました。
            LTは
            * @hidenorigotoさん 「Symfonyの実装パターン」(スライド公開予定なし) 7月のSymfony勉強会の再演でした。行けなかったのでありがたかったです…!
            * @qckanemotoさん 「WordPress.Skeleton」(スライド) 鬼門のWordPressを少しでも楽にというお話。
            * 私から 「CoderDojo Nagoyaへのお誘い」(スライドは全く内容が無いので公開予定なし) CoderDojo Nagoyaのメンターと参加者募集。説明は抜けるわMacBookの電池が無くてデモできないわで、素面の割にいつも以上にグダグダでしたorz 思いがけず、関西から参加のホタルマルさんがCoderDojoのメンター経験者ということで、色々会場や人集めの話を聞くことができました。満足。


            参加された皆様、お疲れ様でした!

            次回は11月のどこかの土日で開催予定です。面白そうだと思った方は是非是非いらしてみてください〜。


            PHPカンファレンス関西2014でフレームワーク四本勝負してきました #phpkansai #symfony_ja

            0

              昨年に引き続き、PHPカンファレンス関西に行ってきました。
              http://conference.kphpug.jp/2014

              今年はLTではなく、フレームワーク四本勝負というもの(東京のPHPカンファレンスで毎年(?)行われるフレームワークアップデートの関西版のようなもの)でSymfonyについて話をしました。

              発表に使ったスライドはこちら。

              @koriymさんの基調講演に感銘を受け、お話の中にあった「継続」という言葉をどうしても入れたくなって、登壇直前までスライドを書き直して臨みました。
              言うはずのことを言い忘れたり、言わなくて良いことも言ったりと個人的な失敗は色々ありましたが、聞いてくださった方に、基調講演からのつながり(つなぐ力!)を少しでも感じてもらえたら嬉しいです。

              <愚痴>
              しかし、運営スタッフの方からの発表依頼の際にはレギュレーションが指定されていたにも関わらず、指定を守ったのが私とLTの『遅れて来た5番目のフレームワーク』だけだったという(ーー;)
              一言で表すと〜のために何日も悩んだのはなんだったのでしょう…。
              </愚痴>

              懇親会で、今後Symfony Componentを使うオープンソースプロジェクトの方や、Symfonyに興味があるという方から声をかけていただき、それぞれ少しお話ししました。はからずも、Symfonyが重い・難しいという印象が浸透してしまっているのを痛感することになりました。
              ファイル数が多いというのを気にする向きもありましたが、軽量と言われるフレームワークでもcomposerを使うのがスタンダードになってきた以上、そこは気にしなくていいのではないでしょうか。
              幸い、Symfonyは、浮気しても待っててくれる心が広い嫁なので、食わず嫌いせずに一度は付き合ってみてほしいと思います!(付き合ってみたら、ギャップ萌えもあるかもしれませんよ?)

              今日一日おつきあいくださった皆様、ありがとうございましたm(_ _)m
              スタッフの皆様もお疲れさまでした。ぜひ来年も来たいです!



              symfony/symfony PR10983 に関する個人的覚書き

              0
                symfony/symfony#10983
                に関するメモです。
                単なる覚え書きなのでいつも以上に乱文ですがご容赦を。
                 

                前提


                私とmockの出会い
                http://phpmentors.jp/post/55127910549

                私も昔(ほんの一年前)はmock使わずテストを書いてました。というのも私の主戦場がsymfony1で、テスト機構はlimeとsfTestFunctionalだったわけです。そこにmockという機能はありませんでした。
                 

                Pull Requestのきっかけ


                仕事でGoutteを使ってみようと思ったのがそもそもの発端です。
                https://github.com/fabpot/goutte
                Goutteは内部でSymfony¥Component¥DomCrawlerを使っているので、必然的に色々な日本語HTMLをDomCrawlerに渡すことになるわけですが、Symfony(に限らず海外ライブラリを使う場合)に頻出の日本語(マルチバイト文字)対応はどうなっている?というのが気になりますよね。それで、色々なHTMLを作ってDomCrawlerに渡してみることにしました。
                正直EUC-JPやSJISのHTMLは読み取り失敗てもしょうがないかなーと思っていたんですが、意外なことにEUCもSJISも大丈夫でした。(よく考えたらsfBrowserやsfTestFunctionalでも既にOpenPNE3の携帯版(SJIS)のテストができていたので意外でもないかも?)
                しかし、不可解なケースも出てきました。
                <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS" />
                はOKなのに
                <meta charset="Shift_JIS" />
                がNGなのです。
                DomCrawlerの中を見てみると、addContent()で後者のタイプのmetaタグから文字エンコーディングを抽出する正規表現が英数+ハイフンしか考慮していないことがわかりました。UTF-8やEUC-JPはそれでも良いですがShift_JISは「_」があるので正常に読み取れていなかったわけです。
                そこを修正して<meta charset="Shift_JIS" />からも正しくShift_JISを読み取れるようにしたいと思いました。
                 

                Pull Requestを出すまで


                正規表現の修正自体は「_」一文字足すだけでさっさと終わるのですが、テストをどう書くか悩みました。

                というのも、従来のテストは、モックを全く使わずに、コンテンツをaddContent()に渡した後、実際にaddHtmlContent()やaddXmlContent()が呼ばれてDOMに追加された結果をテストしていたからです。
                https://github.com/symfony/symfony/blob/cff410507f8485133c19019257f0ea4d3cfcd38f/src/Symfony/Component/DomCrawler/Tests/CrawlerTest.php#L208
                $crawler = new Crawler();
                $crawler->addContent('', 'text/html; charset=UTF-8');
                $this->assertEquals('foo', $crawler->filterXPath('//div')->attr('class'), '->addContent() adds nodes from an HTML string');
                

                DomCrawler::addContent()の処理内容は、まず渡されたコンテンツの種類がxmlかhtmlかを判別し、更にコンテンツのcharsetを判別した後、種類によってaddXmlContent()かaddHtmlContent()を呼び出して、コンテンツとcharsetを渡すというものです。
                今回は私が変更した部分が正しいかどうか、つまりhtml5形式のmetaタグでShift_JISをcharsetとして判別できるようになったかどうかだけをテストしたいのにも関わらず、従来の形式を踏襲したテストを書くとすれば、addHtmlContent()やaddXmlContent()(ひいては、実際にaddHtmlContent()の内部でそのcharsetを渡されるmb_convert_encoding())がその$charsetを受け付けるかどうかも考慮しなければならないのです。もちろん、判別された$charsetはaddHtmlContent()なりaddXmlContent()で利用できるものでなければならないのですが、実際にある$charsetが受け入れられるかどうかはaddHtmlContent()なりaddXmlContent()の関心事であって、addContent()側で知っている必要があるとは思えませんでした。

                ただ、Shift_JISに関しては<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS" />の形式で指定されているときにaddHtmlContent()に$charsetとして正常にShift_JISが渡され(←たぶん)、それを使ってaddHtmlContent()が正常にSJISエンコーディングされたHTMLを扱ってくれるのが既にわかっています。それなら、多少の不安はあっても妥協しても良いという決意ができたので、従来のテストと同じ形式でShift_JISで日本語を読み取るテストをつけて、Pull Requestを出しました。

                追加修正の提案とテスト追加

                Pull Requestを出すと、今まで想定外だった「_」を含むcharset名がでてきたことをきっかけにhtmlの仕様などを読んで、「_」だけでなく「:」と「.」もcharset名として使われる可能性がある、ついでに追加すべきでは?と提案してくれる人が出て来ました。
                正規表現に更に文字を追加するのは別にかまわないのですが、問題はテストです。
                SJISと違って、「:」や「.」を含む文字エンコーディングはhtmlの仕様に載っていたcharset名リストを眺めても全然馴染みがなく、それを使って判別できるとうれしい文字というのも皆目見当がつきません。"test"とか適当な文字列を入れてテストをして、addHtmlContent()側でエラーが出たら、よく知らないエンコーディングのためにmb_*関係を調べる手間をかけることになります。逆に、テストが通ったとしても本当に正しく文字エンコーディングが判別できた結果なのかfallbackのエンコーディングで処理された結果なのかの区別もつけられません。
                そこで、私はCrawlerのインスタンスをパーシャルモックとして作成し、addHtmlContent()を呼ぶ時に第二引数として渡される$charsetをチェックするテストを書き、コミットを追加しました。

                ところが、この後から追加したテストについて、テスト対象のクラス自体をパーシャルモック化したテストはよくないと言われ(:と.について提案してくれたのとは別の人から)、「:」や「.」を含む適切なテストデータが見付けられないと説明したところ、「テストするのが難しいなら、テストしなくていい」と返ってきました。最終的に「:」と「.」を追加したことについてのテストを削除した状態で、私のPull Requestはマージされました。
                マージされて一週間近く、私はまだモヤモヤしています…。

                ちなみに、テストを認めてもらおうと説明する過程で、twitterやfacebookで愚痴っていたところ、@t_wadaさんから、文字エンコーディングを抽出する処理を別メソッドにして、その新しいメソッドに対してテストを書くという方法ならどうか、と教えてもらいましたが、残念ながら「それいいね、それで行こう!」とはなりませんでした。

                まあ、一回のPull Requestでモヤモヤしたからと言って、SymfonyにPull Requestを送ることや #symfony_ja へのコントリビュート(主にドキュメント翻訳)は止めませんし、Symfonyも使い続けます。
                Symfonyは素晴らしいプロジェクトだけど、全員の考え方が一から十まで完全に一致できるわけではない、と思い知ったのでした。


                windows+vagrantでSymfony2プロジェクトの開発環境を作るノウハウ的なもの(Re:Vagrant で Symfony 開発)

                0
                  4/19、Symfony勉強会 #9に行ってきました。
                  全体の流れや私自身の発表については置いておいて、@karakaramさんのLT「Vagrant で Symfony 開発」に関連して、windows環境でVagrantを使ってSymfony2開発をしてきた珍種の一人として、ぜひ情報共有をしておきたいと思いました。
                  (※私自身については、LT冒頭でも言いましたが、最近就職(!)してマカーに転向したので今後あまりwindowsを開発機として使う機会はなくなりました)
                   

                  前提

                  一人で開発
                  開発機のOSはWindows7 professional(メモリが64GBというモンスターマシン^p^)
                  gitはmsysgit利用
                  主に使うフレームワークはsymfony1又はSymfony2 たまにwordpressとかcakeとか
                  visual c++等の自力でphp及びその拡張モジュールをビルドできる環境は無い
                  新規開発案件(PHP5.4/5.5)と保守案件(PHP5.3)を使い分けたい
                  開発に使うIDEはphpstorm
                  原則としてTDDするのでphpunitを使いたい(symfony1の場合はlime使う)

                  Vagrant1.5未満の場合

                  使い方

                  *プロジェクトルートをsynced_folderにする
                  *コードはホスト側のphpstormで書き、テストはゲスト側のコンソールで手動実行(作業中は、phpstormとmsysgitのGit Bashとvagrant sshの三窓を行ったり来たり)
                  *Symfony2のassets:installは常に--symlinkなしで使う
                  (*symfony1のplugin:publish-assetsはホスト側で実行する)
                  *composer installはゲスト側で実行(synced_folderでホスト側にも共有されてくるので、IDEはそれを参照できる)

                  満足

                  *本番とのphpバージョン差異に悩まされることがなくなった
                  *windows版php特有の問題(strftimeのフォーマット文字列とか)に悩まされることがなくなった
                  *よく言われる速度問題はホスト側の超性能でカバーできてた(と、思う。特に速度で不満感じたことなし)

                  不満

                  *jsやcssを更新したときにassets:installを手動実行するのが面倒 *シンボリックリンクが必須のバンドルが使えない

                  Vagrant1.5以後の場合

                  使い方

                  *プロジェクトルートをtype: "rsync"でsynced_folderとして指定
                  *ホスト側のwindowsはcwrsyncを利用してrsyncコマンドを使えるようにしておく
                  *.git .idea app/cache/* app/log/* bin vendor web/bundlesを:rsync__excludeに指定(assetic使う場合はweb/assetic web/js web/cssも除外した方が良いかも)
                  *利用するboxにもよるが、hashicorp/precise64の場合は、初回vagrant up時にいったんVagrantfile上のsynced_folder設定とprovision設定をコメントアウトし、ゲスト側rsyncのバージョンをホスト側rsyncのバージョンと合わせてから、synced_folder設定とprovision設定を再度有効化してvagrant reload --provisionを実行する
                  *作業中に必要なウィンドウがphpstormとmsysgitのGit Bashとvagrant sshの三窓から、rsync-auto専用のGit Bashも加えた四窓に増えた
                  *composer installはゲスト側のプロジェクトルートで実行後、--no-scriptつきでゲスト側の/vagrantでも実行する(IDEで補完を利用するために必要)

                  満足

                  *シンボリックリンクが必須の一部のバンドルを使っていてもwindowsホストで問題なく開発できるようになった

                  不満

                  *rsync-autoにしておくと、excludeにしているにも関わらず時々ゲスト側だけにあってホスト側にないファイル・ディレクトリ(vendorなど)が削除されてしまうことがある

                  トラブルシューティング

                  Vagrant1.5.2以下でrsyncしたディレクトリのパーミッションがおかしい場合→https://github.com/mitchellh/vagrant/issues/3256
                  Vagrant1.5.2以下でrsyncがNo such file or directoryで失敗する場合→https://github.com/mitchellh/vagrant/issues/3230(4/21 12:40訂正1.5.3でも発生してました)



                  利用バンドル数4〜10ぐらいの複数案件で試したのですが、rsyncを有効にしてsynced_folderの共有が速くなったという感じは特にありません。多少は速くなってるのかもしれませんが、少なくとも体感できるレベルではないです。(もともとのPCスペックも関係あるかもですが)
                  今後、Vagrantに双方向rsyncが理想的な形で実装されればいいですが、現時点ではいろいろ手動だったり注意が必要だったりで、素人にはおすすめできない(キリッ)ってやつかもしれません。個人的には双方向rsyncでホスト側での変更内容を都合よく優先してくれっていうのは無理じゃね?と心配してます。


                  Nagoya.php vol3に行ってきました #nagoyaphp

                  0
                    2014/01/25(土)に開かれたNagoya.php vol3に行ってきました!

                    会場提供はFabrica Communicationsさま。ありがとうございますm(_ _)m

                    テーマは、「生PHPでプログラムを作ってみよまい!」。
                    フレームワークは使わず、DBや画面も考慮せず、機能の中核(いわゆるロジック?)だけを皆で作ってみよう、というものでした。

                    自己紹介の後、さっそく@hidenorigotoさんが提示した要件リストを見ながら皆で考えます。

                    まずホワイトボードに登場人物(クラス)を書き出しました。
                    あれも要る・これは要らないなどと意見を出し合い、必要そうなものに絞るのですが、なかなか議論がまとまりません。
                    PHPの勉強会なのに、PHPのコードを書かずに延々一時間ほどホワイトボードと日本語だけを捏ね回していました。
                    ついつい実際の実装(実際のRDBのためのテーブル設計)に思考が引っ張られがちな私が、飽くまでもモデリングに集中しようとする皆を混乱させるという一幕もあり…orz

                    次に、ユースケースを想定して機能を足して行くことにします。
                    先に検討した必要なクラス群を作り、それぞれのクラスのプロパティとして何が必要か、また皆で意見を出し合って、プロパティとgetter/setterを作って行きます。phpstormのgetter/setter自動生成がphpstorm未経験な人達の目を奪っていました。
                    機能を追加していくに当たって、ActiveRecordパターンで行くか?Managerパターンで行くか?というところでは、ActiveRecordパターンを選択。(早々にスパゲティ化したのはこれがまずかったかも?)
                    実装は「〜〜を〜〜して」と口頭で実装内容を言い、@hidenorigotoさんがその通りにコードにして行くという方式で進めました。
                    同じ一日の何時間も経ってない間に、クラスの表すもの(クラスの責務)について混乱が見られたり、コードがスパゲティ化したりと「あるある」感の漂うところで、機能が全て完成しないまま時間切れとなってしまいました。
                    最後の方に@hidenorigotoさんがチラ見せしてくれた、単一のUseCaseごとに単一のクラスを作っているコード群は衝撃的でした。

                    合間合間で、普段の開発事情や使用ソフトについて質問し合ったり教え合ったり。ライブラリやソフトウェアについて「○○がおすすめです使いましょう(ドヤア」という発表こそなかったのですが、飛び交った情報量は結構多かった気がします。
                    特に、WindowsでVagrantを使って開発しているのが私一人ということで、更にphpstorm使用者というのもあり、私はかなり出しゃばって喋りすぎました…。

                    家庭の事情で短時間しか参加できませんでしたが、懇親会でのぶっちゃけトークもとても楽しかったです^^
                    そして、懇親会離脱後三十分で自宅に着いて、やっぱり会場と自宅が近いのはいいなぁと思ったのでした。(遠くからいらした方もいたので、遠くの方には申し訳ないのですが…)
                    2014年は名古屋のPHPコミュニティがもっと盛り上がって、気軽に行ける近くの勉強会やイベントが増えたら嬉しいなー…。


                    私がそれでも名古屋市に住み続ける理由を6つにまとめてみた!

                    0
                      名古屋の人が誰も書いてないので、夫の転勤という主体的でない理由で引っ越してきてそろそろ十年になる私が(無理やりに)書いてみましたよ。

                      1.街がコンパクト(名駅〜伏見〜栄)

                      (福岡も札幌も同じようなことが書かれていますが)ほとんどのことは名駅〜伏見〜栄で用が足りると思われます。
                      知る人ぞ知るカフェやレストランを追求するなら郊外も視野に入れないといけませんが、これは札幌や福岡も同じことだと思うので。←なぞの対抗意識

                      2.エビが豊富で安い

                      エビが豊富で安いです。他地方から来た方が、廻るお寿司屋でネタを見ると驚くと思います。
                      (代りにホタテやイクラが東北・北海道と比べて高い…)

                      3.乳児〜中学生まで医療費無料(所得制限有)

                      超がつく高所得でない限り適用されます。
                      http://www.city.nagoya.jp/kenkofukushi/page/0000009154.html

                      4.小学校にトワイライトスクールがある

                      トワイライトスクールは小学校内に設置された学童保育(みたいなもの)です。年間500円(書き間違いではありません!)の保険代のみで一年生から六年生まで無料で利用でき、人数制限もないため希望すれば必ず利用できます。両親のどちらか(又は両方)がフリーランスだから待機児童になっちゃった、ということはありません。
                      お弁当さえ持たせれば夏休み・冬休みなどの長期休暇もお盆や年末年始を除き預かってもらえます。

                      5.公立優位の地域なので基本的にはお受験不要で教育費が安い

                      例外の一・二校を除いては公立高校のほうが進学実績が良いので、お受験(小学校受験・中学校受験)はしなくてもOKです。
                      宗教上の理由・スポーツ強豪校・両親や祖父母がOBOGなど、どうしても拘りがある場合を除いて、教育内容を犠牲にせずに公立小学校→公立中学校→公立高校という進路を選ぶことができ、お受験必須な地域に比べると教育費が安く済みます。

                      6.首都圏と関西両方にアクセス可

                      首都圏のイベントと関西のイベント、どちらも日帰りで出席することができます。(そのイベントの開催時間がよほどの早朝深夜でなければ。)
                      ちなみに東京に出るには「ぷらっとこだまフリープラン」、関西(大阪)に出るには「近鉄名阪特急(回数券利用)」を使うと旅費を安く上げられます。


                      なお、よく名古屋は車社会と言われますが、住むエリアを選べば自家用車のない生活も十分可能です。
                      我が家は自家用車ありません。私に至っては普通免許も持ってません。電動アシスト自転車と公共交通(JR・バス・地下鉄)とタクシーを使っています。
                      会社勤めをする方なら営業廻りなどで免許必須と言われるかもしれませんが、自宅(又は栄や名駅の)で開発するスタイルの技術者なら、自家用車どころか免許さえ無くてもなんとかなります。

                      【追記】
                      そんな名古屋で、明日Nagoya.php vol.3があります。テーマは「生PHPでプログラムを作ってみよまい!」です。
                      http://nagoyaphp.doorkeeper.jp/events/7716

                      名古屋周辺のPHPerの方・PHPに興味がある方(無い方も?)は参加してみてはいかがでしょうか?


                      今すぐSymfony2.4でKnpPaginatorBundleを使うためのcomposer.json設定

                      0
                        2013/12/3に、Symfony2.4が正式にstable(安定版)としてリリースされました。
                        http://symfony.com/blog/symfony-2-4-0-released

                        デバッグツールバーのFormパネル、セキュリティ(認証)カスタマイズの柔軟性アップなど、(開発者に)嬉しい機能が新たに追加されています。
                        私も早速、Symfony2.3を使って開発したプロジェクトをSymfony2.4に対応させてみました。(諸事情あって本番サーバーには適用できなかったので飽くまで実験として、ですがorz)

                        まず、変更したのはcomposer.jsonです。symfony/symfonyを"2.3.*"(2.3系列)から"~2.3"(2.3以上)に変更します。
                        -        "symfony/symfony": "2.3.*"
                        +        "symfony/symfony": "~2.3"
                        

                        サードパーティのバンドルを何も入れていない場合は、ここまででcomposerでsymfony/symfonyをupdateすればそれで完了です。
                        $ composer update symfony/symfony
                        あとは、自分の書いたバンドルについて2.4でエラーが出るようなら修正しましょう。

                        私はKnpPaginatorBundleを入れていたので、デバッグモードでEventDispatcherが変更されたことによる影響をもろに受けて、paginatorを使う一覧系ページが軒並みエラーになりました…。
                        Argument 1 passed to Knp¥Component¥Pager¥Paginator::__construct() must be an instance of Symfony¥Component¥EventDispatcher¥EventDispatcher, instance of Symfony¥Component¥HttpKernel¥Debug¥TraceableEventDispatcher given,

                        エラーメッセージでGoogle検索すると割とすぐに「もう修正されてるよ」という情報が出てくるのですが、
                        https://github.com/symfony/symfony/issues/9089
                        https://github.com/KnpLabs/knp-components/pull/68
                        https://github.com/KnpLabs/knp-components/pull/88
                        https://github.com/KnpLabs/KnpPaginatorBundle/issues/223

                        KnpPaginatorBundleとKnpComponentsの修正された部分がまだKnpLabsから正式版としてリリースされていないために、単にupdateしても「新しいリリースがないよ」という趣旨のエラーメッセージが出て終わってしまいます。
                        色々試行錯誤したりソースを読んだりした末、KnpComponentsは1.2.4以上、KnpPaginatorBundleはmasterを使わなくてはいけないということがわかりました。
                        そこで、composer.jsonにバージョンを指定します。
                        -        "knplabs/knp-paginator-bundle": "2.3.*",
                        +        "knplabs/knp-components": "~1.2.4",
                        +        "knplabs/knp-paginator-bundle": "dev-master",
                        

                        knp-paginator-bundleのdev-masterだけ指定すると、knp-componentsのバージョンが自動的に1.2.3になってしまうのでknp-paginator-bundleより先にknp-componentsを1.2.4以上として指定しました。
                        (私はこの組み合わせを見付けるのに2時間もかけてしまいました…orz)

                        もしminimum-stabilityをstableにしている場合は、もう一点、composer.jsonの変更が必要です。
                        knp-componentsがまだ安定版じゃないので、stable指定だとせっかくのベストな組み合わせが弾かれてしまいます。stableでなくdevを指定し、かつprefer-stableをtrueにすることで弾かれないようにします。
                        -    "minimum-stability": "stable",
                        +    "minimum-stability": "dev",
                        +    "prefer-stable": true,
                        

                        ここまで来たら、後はcomposer updateするだけです。

                        なお、KnpPaginatorBundleやKnpComponentsのリリース状況によっては、この指定は不要になる予定です。
                        早く1.2.4を安定版にしてよ〜と叫んでる人がKnpComponentsのissueにたくさんいるので早晩リリースされるでしょう。たぶん。
                        が、それまで待てないという方は、ぜひ上記の組み合わせをお試しください。



                        PR

                        calendar

                        S M T W T F S
                             12
                        3456789
                        10111213141516
                        17181920212223
                        24252627282930
                        31      
                        << March 2024 >>

                        twitter

                        selected entries

                        categories

                        archives

                        recent comment

                        • djangoテンプレート上でmodelのメソッドに引数を渡す方法(djangoで出勤簿アプリ試作中♪)
                          GavannITサービス-なりとみ
                        • 私がそれでも名古屋市に住み続ける理由を6つにまとめてみた!
                          bose wireless speaker
                        • FastCGIでdjango…400エラー???
                          levi's
                        • さくらインターネットdjangoが突然500エラー!?(Pythonバージョンアップされてた
                          salomon running shoes
                        • 私がそれでも名古屋市に住み続ける理由を6つにまとめてみた!
                          louboutin shoes
                        • FastCGIでdjango…400エラー???
                          yeezy boost 350
                        • さくらインターネットdjangoが突然500エラー!?(Pythonバージョンアップされてた
                          jordan 11
                        • Silexでエラーページをカスタマイズする方法 : Symfony Advent Calendar 2011 - day 12
                          pandora jewelry
                        • django対symfony 日本語メール送信(その1 symfony編)
                          nike air vapormax
                        • 解決!XREAでCGI版Pythonを使ってdjangoを動かす(人柱?)
                          kate spade

                        recent trackback

                        • HTMLの表(TABLE)のセル(TD)に斜線を引くjavascriptライブラリ slash.js 作っちゃいました
                          常山日記
                        • django対symfony 日本語メール送信(その1 symfony編)
                          CPA-LABテクニカル
                        • CodeIgniterでユーザー認証
                          されどLAMPな日々
                        • 久々にdjangoを最新版にしたらHTMLがエスケープされちゃった!!(解決済み)
                          常山日記
                        • FastCGIを諦めてmod_pythonを使う。Apacheのアップグレード
                          サーバー用語集
                        • さくらインターネット、sqlite3でdjango@CGI版を使う際の設定メモ
                          常山日記
                        • さくらインターネット スタンダードプランでdjango使ってる方、DBは?
                          mitszoの日記
                        • python多次元リストをsort(並べ替え)する方法?
                          mitszoの日記
                        • フォームから送信した値とrequest.POSTの挙動($_POST@PHPとの比較)
                          Humming Via Kitchen
                        • 日本語テキストをtruncate@django(Python全般にも??)
                          常山日記

                        recommend

                        links

                        profile

                        search this site.

                        others

                        mobile

                        qrcode

                        powered

                        無料ブログ作成サービス JUGEM