恥知らずのウェブエンジニア -web engineer, shameless

これは一歩を踏み出すことができない者たちのブログ

Test Engineers Meetup #1に行ってきた

test SET

Test Engineers Meetup #1行ってきました。

connpass.com

ろくにテストを自動化できていない自分としては、テストの実装/運用ノウハウ聴けるかなと期待して行ったのですが、いい意味で違ってましたw

発表資料だったり発表中紹介されたもの

www.slideshare.net

www.slideshare.net

speakerdeck.com

speakerdeck.com

メルカリのBe ProfessionalなQAチームの紹介 - mercan（メルカン）

kintoneチームを支えるSeleniumテスト

実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ

個人的所感

実際の開発テクニックというより各社のテストエンジニア組織の成り立ち、立ち位置、業務範囲、よかった/悪かったこと等がメインでした。

以下、個人的に印象に残ったこと。

  • 各社テストエンジニア組織を作り始めている
  • テストエンジニア組織はプロダクトに属する部隊とツール/基盤系部隊の横串/縦串の形を取っているのが多めっぽい
  • テストエンジニアは必要なスキルセットがネイティブ/フロントエンド/サーバー/インフラなどかなり広い
  • テストを自動化するだけではなく、プロダクトの品質保証/向上、開発効率向上をゴールにしている
  • テストエンジニアを組織化することで、属人化していたノウハウの共有、標準化。テストツールの基盤作りをすることができた。
  • しかしテストエンジニアが事業/プロダクト側から離れることにより、プロダクト側の知識が少なくなり適切なアクションが取れないことも。
  • それの対策のためにもテストエンジニア組織かつプロダクトに属して現場との認識を合わせるようにしている
  • でもそれだとテストエンジニア組織がスケールしていかない面もある
  • なのでテストエンジニア組織は現場に入るのではなくツールなどのサポート等に徹する会社もあり
  • 逆にプロダクトオーナーと密に関わり、プロダクトの品質を一緒に考え、向上を図っていく会社もあり
  • テストエンジニアの価値、成果を数値化が難しい
  • プロダクトの品質はどう測定する？
  • テストだけをしているだけではないので、テストエンジニアという肩書きに違和感を覚えている人も

もっとも印象的だったのは、テストだけではなくプロダクト/開発の品質、生産性向上をゴールとしているということでした。


個人的な想像ですが、、、

テスト自動化周りが発端になったものの、いざやってみるとテストだけでは品質、生産性の向上は十分ではない。(ましてやテストエンジニア=多くのスキルを持った優秀なエンジニア)

かと言ってプロダクトに深入りするとテストエンジニアを組織化した意味がなくなってしまうのではと感じる会社があったり、そんなの関係なくプロダクト/開発の品質、生産性向上を図ろうとする会社があったりまだまだベストプラクティスがないなか各社手探りで答えを見つけようとしている状況なのかと感じました。

また「テストエンジニアに興味を持ったきっかけは？」という質問で「品質保証/向上には0か1という答えがない。だからわくわくした」という回答もとても印象に残りました。


自分はというとまずは挫折しっぱなしのテスト自動化再挑戦と自分なりにプロダクトの品質/生産性の向上に何ができるか今一度考えてみようと思います><

きっかけ頂きありがとうございました！

f:id:ogataka50:20160915011639j:plain

【翻訳】ハワイ大学アメフト部のアメリカンな奨学金祝い

翻訳 hawaii football

今朝facebookをながめていたら、最高にハッピーな動画を見つけたのでシェア&翻訳。まずは何より動画を見てください。

ハワイ大学アメフト部のブロディ・ナカマ選手が奨学金を手に入れたのをコーチ、チームメイトがなんともアメリカンな方法でお祝いしています。

彼はジャンプしたくなかったが、ジャンプせずにはいられなかった　

By Robert Kekaula

ハワイ大学のアメフト選手ブロディ・ナカマ(180cm,115kg)はレインボー・ウォーリアーズ（ハワイ大学アメフトチーム）最終学年のシーズンに奨学金を獲得した。

カルフォルニア州サンタクララで生まれ、スペシャルチームのロングスナッパーでキャリアを通して堅実にこなしていた。彼は当然のようにロングスナップを決めていた。

「両親は僕を大学に入れ、アメフトをさせてくれるために多くの事を犠牲にしてくれた。奨学金獲得は僕にとって特別な事、きっと両親の助けになる」

奨学金は普通のオファーではなく、ロロビッチコーチの完璧なプランでオファーされた。

彼は金曜の練習を早めに切り上げ、「プールパーティ」に選手達を連れて行った。プールの飛び降り台は始め立ち入り禁止でした。でも選手達に促されて、ロロビッチコーチは飛び降り台を渋々開放しました。

誰かが登り出す前に、口火を切らせるため1人の選手が指名されました。その選手がブロディ・ナカマでした。

「コーチが僕の名前を呼んで、なんでコーチが僕にこんなことをさせるか考えたよ。完全に混乱したよ」とナカマは言う。

彼は飛び降り台からジャンプしたくなかった。でもチームメイトが彼の名前をコールし出したので、選択の余地なくなり、台を登り始めた。

「僕はとても緊張して、何回か息を止めて、息を飲んだりしたよ」

ナカマが飛び降り台の一番上に登った時、彼の名前が書かれている封筒を見つけた。封筒の中に奨学金のオファーが書かれているなんて彼は知る由もなかった。

言うまでもなく、ナカマはとても感動していた。

「その少し時間、言葉にもできず、気持ちを抑えることができなかった」

ナカマ潤んだ目を拭い、それからためらいもなく、ジャンプした。

original

He Didn't Want to Jump, He Had to Jump - Honolulu, Hawaii News and Weather - KITV Channel 4

アメリカの大学でスポーツでの奨学金をもらえるには大きな意味があります。

カレッジスポーツは文武両道が原則なので、スポーツ/学業共に成績が優秀でなければいけません。スポーツ推薦的なものもあるのですが、一定の成績以上を取るのが絶対です。このブロディ選手のプロフィールを見てみると学業優秀者しか選ばれないacademic all-MW teamに1年生から3年連続で選ばれていました。

Brodie Nakama - 2016 Fall Camp Football Roster - Hawaii Athletics

スポーツ一流校であるハワイ大学で厳しい練習をこなしつつ、学業で秀でるためにはかなりの努力が必要でしょう。

そしてカルフォリニア生まれでハワイ大学に行くことは家庭にもある程度の金銭的負担がかかるでしょうし、本人もそれを痛いほど感じていたようです。

そうした背景を知った後で、再度動画を見ると途中で出てくるパリピ系な学生と違いブロディ・ナカマ選手の実直そうな性格がありありと感じられます。

最初に飛び降り台からのジャンプを指名された時は、緊張して困惑してジャンプすることに躊躇している様子

そこから奨学金をもらえることを知って、感激して感情を抑えられないでいる様子

その後ためらいなくジャンプし、それを祝福しようとチームメイト全員がプールに飛び込む様子

本当に映画のワンシーンのようです。

それと同時に大学のスポーツチームが複数のカメラアングルを使って映像にしている所にアメリカのエンターテイメント文化のすごさを感じました。

チームPVとかならある程度予算かけてしっかり作り込むとかはわかるのですが、今回に関してはシーズン前のちょっとしたイベントなのにこのクオリティを出してしまう所がすごい。

ブロディ・ナカマ選手にも注目ですが、今年のハワイ大学には伊藤玄太というRBの選手が入学しているので、こちらも要注目ですね！

英語記事の翻訳やってみる

翻訳

最近、やっぱ英語できるといいなーって思うことが多くあります。 ドキュメントやstack overflowを見る程度なら特に感じなかったのですが、githubのissueの流れを見たり、海外支社のある会社だとレビューなどもすべて英語がやるらしく。

この前も気になったissueがあったので流れをググりながら見た結果、全然大した内容がなかったりで、、、気軽にざーっと読めるといいなーだったりワンチャン海外で働いてみたいなーとかもあり、英語の勉強をしようと決意しました。

なのでこの１、２週間toeicの教材、英会話アプリやyoutubeの英会話チャンネル見たりしてます。それの一環として英語の翻訳やってみました。

翻訳したのはコチラ www.theplayerstribune.com

【翻訳】「ザ・パス」 リカルド・ロケット - 恥知らずのウェブエンジニア

2015/7/24の記事なんですが以前、翻訳された記事を見た時ひどく感動して印象に残っていたので翻訳してみました。 なので、完全に翻訳ではなくすでに話の流れも知っていて、翻訳中何回か↓のものをチラ見しながらやったものです。

パスが捕れていれば2連覇...WRロケットの手記 - NFL JAPAN.COM編集部オフィシャルブログ

プロスポーツ選手というと全員生まれ持った特殊な才能を持った特別な人間かと捉えてしまいがちですが、この記事からは何もない所から、仲間と共に努力、高め合い一度は栄光を手にした後、深い挫折をし、さらにそこから立ち上がろうとする生身の姿が感じられます。 しかし、リカルド・ロケットにはその後過酷な運命が待っているのですが・・・（その記事もあったのいつか翻訳してみたい）

いざ翻訳をしてみると知らない単語があったり、日本語にはない言い回しなどがあって、これなら楽しみながら英語の勉強になりそうです。 とか言って、いつもの三日坊主になる予感もありありですが、1週間に1記事程度翻訳していければと思っています。

特にスポーツに限らずニュースだったり、映画のワンシーン、OSSのドキュメントとかその時興味あるものをやってみようかと。

【翻訳】「ザ・パス」 リカルド・ロケット

翻訳 NFL

original by www.theplayerstribune.com


Butler picks off Wilson to seal Patriots Super Bowl XLIX victory

あのビデオを見ることができない。見ると立っていられないだろう。人々は「あれは完璧なインターセプトだった」と言う。俺がエンドゾーンに入っていたカメラアングルもあると言う。みんな第49回スーパーボウルの最後のプレイについて色々なことを言う。俺は知りたくもない。そういう話になる度、俺は背を向ける。

でもすべての動きを覚えている。１秒ごとに。ハドルに向かい、そしてラッセル・ウィルソン（ラス）がみんなを見て、「いくぞ。やってやるんだ」と言ったことを覚えている。俺たちが勝つことを信じきっていた。疑いもしていなかった。信じていなければラスを見られない。ラス以上に自信に満ちたやつを俺は見たことがない。彼は一年中練習していたプレイをコールした。俺たちはそのプレイをシーズンで同じようなシチュエーションで３回コールし、すべて完璧に成功させた。絶対に止められないプレイだ。

そのプレイはいつも俺にボールが来た。やるか、やられるか。やろう、スーパーボウルを勝ちに行くんだ。俺はセットポジションに向かう、スタジアムの耳が痛くなるような歓声の中。逆サイドを見ると、ダグ・ボールドウィンをダレル・リーヴィスがカバーしている。俺たちが望んでいたマッチアップだった。何か考えたり、神経質になる前に、ボールがスナップされた。俺は走り出し、ジャーメイン・カースが俺の前でピックに入った、100回はやったことだ。俺はラスを見た、ラスを見た、、、ボールが来るのが見えた。ボールが来るのが見えたんだ。その景色が止まることはない。

f:id:ogataka50:20150201205915j:plain

次に起こったことは、俺はフィールドに膝をつき、「パス失敗か？」って周りを見た。ペイトリオッツのサイドラインを見ると、トム・ブレイディが飛び跳ねていた。そして俺たちのサイドラインを見るとみんな呆然として、うなだれていた。

俺はあの痛みを忘れることはないだろう。絶対に。

幼少期、俺はジョージアの汚い道で自転車を乗り回す汚い子供だった。TVで見られるような人間になるなんて考えもしなかった。高校になるまで、俺の足が速いなんて知らなかった。陸上のコーチが俺をチームに入るよう説得してきた。俺は、「コーチ、トラックを走るようなやつはバカにされる、俺はモテたいんだ」でも最後には高飛びをやるように説得された。ある日、4×4を走るはずの部員が来なかった時、コーチは俺に言った、「リカルド、君が必要なんだ」

俺はその時、バスケットボールのハーフパンツに、重いエアジョーダンを履いていた。「コーチ、でもさぁ・・・」

コーチは言った、「代わりはいなんだ、走るだけでいいから」

そして、俺はトラックに入り位置についた。他のやつは全員スパイクを履いて、ゴールドのチェーンを付けて、ナイキと契約しているようなイケてるサングラスをしていた。バカにしてるのか？面倒なことに巻き込みやがってというようにコーチを見た。

バン！スタートのピストルが鳴った。俺はエアジョーダンで走り、そのリレーのベスト記録を出した。それから俺はずっと走り続けている。俺のスピードは2011年のNFLコンバインで噂になった。フォートバレー大学の４年生の時に１タッチダウンしかキャッチしてないのにだ。でもそれだけでドラフト指名されることはなかった。俺は未熟だった。ありがたいことに、シーホークスが俺の姿勢を気に入ってくれて、プラクティススクワッドにしてくれた。

f:id:ogataka50:20150724090834j:plain

2011年のクリスマスイブ、49ers戦のメンバーになることができた。これ以上にいい筋書きはない。49ersは父が大好きなチームだ。父は試合の応援に来てくれた。ゲームの最初のプレイ、俺はハドルの中にいてその時QBだったタバーリス・ジャクソンがダブルライト、ダブルゴーをコールした。彼は冷静な目で「お前に投げるから、ただ走れ」と言った。

ハドルを離れたくなかった。一瞬そこで凍りつき、ハドルブレイクした。俺は定位置に小走りで向かった。対面にはカルロス・ロジャースがいて、彼を見て思った。「マジかよ、マッデンで彼を使ってインターセプトしまくったぞ。これはクレイジーだ！」

次の瞬間考えたのは、「彼は俺より早くはない。いこう。やってやるんだ」

ボールがスナップされ、スタジアムが静まり返り、俺は走り出した。10ヤード、20ヤード、30ヤード、40ヤード走り、俺は顔を上げると、ボールが浮いていて、ボールの回転がスローモーションで見えた。まるでコマ送りの映画のように。俺は手を伸ばし、ボールをキャッチした。ドカン。俺はグランドに叩きつけられた。次に知ったのは観衆からのクラウドノイズの轟音とサイドラインの仲間が俺を包んだ。まるで試合に勝ったかような狂騒だった。まだ第一クォーターなのに。

俺はそのシリーズのあとサイドラインに戻り、スタンドにいる父に向け言った。「メリークリスマス」と。

f:id:ogataka50:20140202224232j:plain

NFL最初のプレイでカルロス・ロジャース相手にキャッチするなんてクレージーだから、俺はこの話をいつもすんだけど、誤解される。あのゴールートはスピードで勝ったと。それだけでリーグにいることはできない。シーホークスのプレイブックには600以上のプレイがあり、加えて書かれていないリードやバリエーションがある。ロードの試合の時は騒音のせいでラスからのコールが聞こえない時もある。だからもし彼が違うリードをしたらサイン、ウィンクあるいはただ直感で連携を取らないといけない。

あそこはクレージーな場所なんだ。NFLのゲームには身体能力や血筋以外のことがある。そうでなければスーパーボウルに２年前連続で出場することはできなかった。俺たちのほとんどはドラフト下位、ドラフト外、ドラフト外の無名選手だった。成果を出し続けることによってのし上がってきた。どのチームも精神力があると思うかもしれないが、本当はそう多くはない。俺はシーホークスと契約後の最初の夜を今でも覚えている。ホテルに向かうとルームメイトのダグ・ボールドウィンがすでにいびきをかいて寝ていた。

俺は「ゴメン、起こしちゃったかな」と言うと、 彼は「いや、全然いいよ」と、そして 「フォートバレー大学のリカルド・ロケットだ」 「スタンフォード大学のダグ・ボールドウィンだ」 俺たちは両方ドラフト外。彼の方が試験が少し難しいぐらい。

それからベッドに戻って言った「早く寝なきゃ、俺達には明日やらなきゃいけないことがあるんだ」

その日からそれは変わっていない。俺たちは早起きして、練習施設に向かい、遅くまで居た。俺たちは同じランチテーブルの同じ席で食事をした。ダグか俺どちらか疲れている時はお互いを「ドラフト外だ。お前はカットされる寸前だ」というように見合った。お互いにそれで高め合った。ダグと最初に出会った夜、俺は車を持っていなかった。アパートもなかった。大学から持ってきた着替えの入ったバッグ、レシーバーグローブとホテルの部屋しかなかった。それが全てだった。数百ドルと一つの夢だけだった。

2013年スーパーボウルチャンピオン、2014年スーパーボウル出場を振り返って、俺は感謝しなければいけない。それらは連覇できなかった痛みを和らげるだろうか。絶対にそんなことはない。人々は敗戦の後、「マルコム・バトラーは完璧なインターセプトを決めた。彼を称えるべき」と言ってくるようだった。

そんなのは馬鹿げている。それは誰かがあなたの兄弟を撃ったけど、それはいいことだったと言うようなものだ。痛みが和らぐことはない。もう一度あの場所に戻って、スーパーボウル制覇する以外に痛みを取り除くことはできない。ラッキーなことに周りにはいいやつがいるが、このオフシーズンは本当に相当しんどかった。ベッドルームの天井だけを見る夜もあった。他の人が言うことなんか気にしなかったが、チームメイトが俺をどう考えているか心配だった。

それから4月、俺はラッセルからメールを受け取った。彼はハワイで選手だけのワークアウトを開催していた。今年で3年連続。俺たちがそこで出会った時、それはまるで映画のようだった。俺は太平洋を見下ろす岸壁に立っていて、そこには文字通りクジラが潮を吹いていた。「ジョージアのアルバニーからここまで来たのか」と考えたのを覚えている。

f:id:ogataka50:20141006193632j:plain

俺は長い間太平洋を見ていた、そしてラスが歩み寄ってきた。スーパーボウルのあとにお互い会ったのはそれが初めてだった。俺は眠れない夜がたくさん有ったことを告白した。彼は俺もだと言った。それから彼は俺を見て「俺たちはあの場所に戻る。そしてもし同じ状況になったら、またお前にボールを投げる。今度こそ上手くいく。お前を信じている」

それはリハーサルされたスピーチじゃなかった。こういうことを言うクォーターバックがいるが、言ってるそばから本人が信じていないことがわかってしまうことがある。ラスの特別な所はフットボールを越えて何が起こっても他人を信じる所だ。疑り深い人にはわからないだろう。

俺は「わかった」と言った。

俺たちはハグをして、その時は終わった。それだけで十分だった。俺たちはアロハシャツを着て岸壁に立ち、陽が沈むのを眺めていた。大きなクジラが辺りを漂っていた。

俺は時々自分の頭を振らないといけなくなる「Yo、これはマジで現実なのか？」って

phpmdでコード解析＋チェックルールのカスタマイズしてみる

php phpmd

youngforever.hatenablog.com

前回のphpcsに続きコーディングの品質向上のためphpmdを使うようにしてみました。

PHPMD - PHP Mess Detector

phpmdは潜在的にバグになりそうなコードや改善の余地があるコードなどを検出してくれるツールです

phpmdインストール

公式通り、composer.jsonに下記を追記してcomposer installします

{
    "require-dev": {
        "phpmd/phpmd" : "*"
    }
}

使い方

コマンドラインで実行する際は下記のように実行できます。

phpmd /path/to/file xml codesize,naming,cleancode

xml以後のオプションで検出ルールを指定します。 ルールが設定してあるxmlはvendor/phpmd/phpmd/src/main/resources/rulesets/以下にあります。

デフォルトでは下記があります。

またそれぞれのルールの実装はvendor/phpmd/phpmd/src/main/php/PHPMD/Rule/にあります。

なので、ルールのカスタマイズするには、新規にruleを定義したxmlを作成して、それに対するチェックの実装を行っていく感じになります。

カスタマイズルールを作ってみる

今回はtypoチェックを実装してみました。

まずカスタマイズルール用にxmlを作ります。

vi vendor/phpmd/phpmd/src/main/resources/rulesets/myStandard.xml


<?xml version="1.0"?>

<ruleset name="My Standard Rules">

    <description>
This ruleset contains a my standard rules.
    </description>

    <rule name="CheckTypo"
          since="0.2"
          message = "Maybe typo. {0} : {1} -> {2}"
          class="PHPMD\Rule\MyStandard\CheckTypo"
          externalInfoUrl="#">
        <description>
            <![CDATA[
Maybe typo.
            ]]>
        </description>
        <priority>1</priority>
        <properties />
        <example>
            <![CDATA[
protocal->protocol
recompence->recompense
            ]]>
        </example>
    </rule>
</ruleset>

上記のように定義して、PHPMD\Rule\MyStandard\CheckTypoにチェックルールの実装を行っていきます。

typo例はこちらのものを参考としました。

Wikipedia:Lists of common misspellings/For machines - Wikipedia, the free encyclopedia

既存の実装を元に下記のように実装してみました。 ./resources/typoList.csvにtypo単語リストを置いています

vendor/phpmd/phpmd/src/main/php/PHPMD/Rule/MyStandard/CheckTypo.php


namespace PHPMD\Rule\MyStandard;

use PHPMD\AbstractNode;
use PHPMD\AbstractRule;
use PHPMD\Rule\FunctionAware;
use PHPMD\Rule\MethodAware;

/**
 * This rule CheckTypo.
 * typo check
 *
 */
class CheckTypo extends AbstractRule implements MethodAware, FunctionAware
{

    private static $typoList = [];

    /**
     * This method checks typo
     *
     * @param \PHPMD\AbstractNode $node
     * @return void
     */
    public function apply(AbstractNode $node)
    {
        $typoList = $this->getTypoList();

        foreach ($node->findChildrenOfType('Variable') as $variable) {
            $image = $variable->getImage();
            foreach ($typoList as $key => $value) {
                if (preg_match("/$key/", $image)) {
                    $this->addViolation($variable, array($image, $key, $value));
                    break;
                }
            }
        }
    }

    /**
     * get typoList
     * @return void
     */
    public function getTypoList()
    {
        if (self::$typoList) {
            return self::$typoList;
        }
        $typoList = [];
        $fp = fopen(dirname(__FILE__) . "/resources/typoList.csv", "r");
        while (!feof($fp)) {
                $tmpArr = fgetcsv($fp);
                $typoList[$tmpArr[0]] = $tmpArr[1];
        }
        self::$typoList = $typoList;
        fclose($fp);

        return self::$typoList;
    }
}

実行はこんな感じで、 phpmd /path/to/file xml myStandard

既存の実装を元になんとなくやってみましたが、変数名のtypo検出ができました！

こんな感じでカスタマイズルールを実装することでプロジェクト共通で品質向上やレビューの負荷軽減等していけたらと思いますん。

phpcsでカスタマイズしたコーディング規約をチェックする

php phpcs

正直なところ、今まであまり厳格に規約に沿ってコーディングしてきませんでした。

  • ある程度守っていればいいだろ
  • 統一させたいなら整形ツール的なやつで自動化すればいいじゃん

など思っていたんですが、OSSなど作っていきたいと考えた時、ちゃんと標準的なコードを書きたいと思い、コーディング規約をしっかり守りたいと考えるようになりました。

また何が標準かというのを理解するために整形ツールなどではなく、phpcsを使ってコーディング規約をチェックするようにしました。

phpcsインストール

github.com

PHP_CodeSnifferをインストールすることでphpcs,phpcbfなどがまるっと使えるようになります。

composer global require "squizlabs/php_codesniffer=*"

ドキュメント通り、composerでさくっとinstall

使い方、規約のルール指定

Usage · squizlabs/PHP_CodeSniffer Wiki · GitHub

phpcs --standard=PSR2 /path/to/file

などで指定したコーディング規約でチェックをすることができます。

規約ルールのカスタマイズ

現在のプロジェクトのコーディング規約はフレームワーク側の兼ね合いもありPSR2をベースにして、一部フレームワーク側の合わせたものになっています。

なので、そのままPSR2を適用すると意図しない規約のチェックが行われるので、PSR2をベースに一部をカスタマイズしたものを作成しました。

vendor/squizlabs/php_codesniffer/CodeSniffer/Standards以下に各種規約ルールがあります。

ここにカスタマイズした規約ルールを作成し、その規約を指定してphpcsを実行するイメージです。

//MyPSR2という規約ルールを作成する
mkdir vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/MyPSR2 
vi vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/MyPSR2/ruleset.xml

今回はPSR2をベースにインデントを4タブ、いくつかのルールを除外したものを作成しました。

exclude nameはphpcs -sなどで実行して除外したいルールを追加していく感じです

ruleset.xml


<?xml version="1.0"?>
<ruleset name="MyPSR2">
 <description>The MyPSR2 coding standard builds on the PSR2 coding standard.</description>
 <arg name="tab-width" value="4"/> <!-- タブ -->

 <exclude-pattern>*/Tests/*</exclude-pattern>

 <!-- Include the whole PSR2 standard except FunctionComment, which we override -->
 <rule ref="PSR2">
  <rule ref="Generic.WhiteSpace.DisallowSpaceIndent"/>
   <rule ref="Generic.WhiteSpace.ScopeIndent">
    <properties>
     <property name="indent" value="4"/>
      <property name="tabIndent" value="true"/>
     </properties>
   </rule>

  <exclude name="PSR1.Files.SideEffects.FoundWithSymbols"/> <!--  -->
  <exclude name="PSR2.Methods.FunctionCallSignature.Indent"/> <!--  -->
  <exclude name="PSR1.Methods.CamelCapsMethodName.NotCamelCaps"/> <!--  -->
  <exclude name="PSR1.Classes.ClassDeclaration.MissingNamespace"/> <!--  -->
  <exclude name="Generic.WhiteSpace.DisallowTabIndent.TabsUsed"/> <!--  -->
  <exclude name="Generic.WhiteSpace.DisallowTabIndent.NonIndentTabsUsed"/> <!--  -->
  <exclude name="Generic.WhiteSpace.ScopeIndent.Incorrect"/> <!--  -->
  <exclude name="Squiz.Classes.ValidClassName.NotCamelCaps"/> <!--  -->
 </rule>

</ruleset>

ルール作成後に、

phpcs --standard=MyPSR2 /path/to/file のように実行すればカスタマイズされたルールで規約のチェックをすることができます。

f:id:ogataka50:20160705182312p:plain

これでしっかりコーディング規約にそったコードを書いていけますね！ 次はいちいちコマンドラインから実行するのもアレなので、エディタからコーディングチェックできるようにしていこうと思います。

New Relic ハンズオン・ワークショップ in Tokyoに行ってきた

newrelic

newrelic.com

行ってきてみました。

new relic使っているものの、transactionからどの処理が遅いか的な使い方しかしてなかったので。

f:id:ogataka50:20160531125042j:plain

スピーカーはNew Relic の Joe LoCascio さん。前編英語かと思いきやしっかり通訳の方がいらっしゃって一安心。

アジェンダ

f:id:ogataka50:20160531131604j:plain

ざっくりメモ

new relicの大枠の機能

  • APM

    • サーバー側のプロファイリング

  • BROWSER

    • フロントエンド側のプロファイリング

  • SYNTHETICS

    • サーバーの死活監視。ブラウザテスト的なこともできるらしい

  • MOBILE

    • ネイティブアプリのプロファイリング

  • SERVERS

    • サーバーのリソース監視

  • PLUGIN

  • INSIGHTS

    • new relicで収集したデータをSQL的な感じ抽出してデータ分析できる

apdex

  • レスポンスタイムからユーザ満足度を図った数値

  • 基準レスポンスタイムを設定し、そこから割合判定

  • apdex計算式

    • apdex =　(satisfied + (tolerating / 2)) / total requests

    • satisfied -> 満足。レスポンスタイムが基準値以下

    • tolerating -> まあまあ。基準値の４倍以下

    • flustrated -> 不満足。基準値の４倍以上

key transaction

  • 特定のtransactionをkey transactionに設定することでより詳細な情報を取得できるようになる

  • x-ray sessionで関数レベルで分析できる

    • あとから調べたら現状Java, Python, Rubyのみ対応の模様・・・

error analytics

  • クラスごと、トランザクションごとグルーピングできる
  • error traceもできる
  • newrelicのモジュールを追加すれば、newrelic専用エラー出力もできる

newrelicのAPIでデプロイメントマーカーを設定できる。

  • リリース前後での変化を可視化

custom dashboard

  • 監視したい情報を自分用にピックアップできる

using alerts

  • アラートポリシー設定可能

  • アラート条件、通知チャンネル柔軟に設定可能

所感

  • やろうと思えばもろもろ監視系すべてイケるっぽい

    • でもすでにmuninとかもあったり、他の監視ツールとの住み分けなり統合なり考えないといけなそう

  • 色々できそうだけどnewrelicのオーバーヘッドはないのだろうか・・・

    • 過去にnew relicからマスターDBへ定期的にデータ取得してたりとかあった

    • 野良のプラグインとか要調査が必要そう

  • どうやらもろもろphp対応は後回しの模様・・・

    • 最近風当たりの強さを感じる

  • 頂いたnew relic Tシャツが意外とアグレッシブ

f:id:ogataka50:20160531215105j:plain

でした！