CakePHP3.5.2にアップデートしました！

こんにちは。先日ついにスプラトゥーン2を手に入れて、 日夜練習を頑張っている結城 (@super_manner)です。 毎日google先生で「ガチマッチ 勝てない 自分のせい」とググって枕を濡らしています。

さて、本日CakePHPのマイナーアップデートがありましたので、いつものごとく、ちょっとした所感、追記を添えてお知らせしたいと思います!!

bakery.cakephp.org

今回の変更点まとめ

• Http\Clientは、非標準のプロパティを持つCookieを解析しなくなりました
  • CakePHPのソースのこのあたりに標準プロパティがセットされているので、これ以外のものをセットしても解析ができません
• CookieComponent設定は、以前のバージョンとの下位互換性があります
  • secureとhttpOnlyの部分の型がキャストされることで互換性を保ったようです
• poファイルの解析では、複数のメッセージの後に単一メッセージが定義されている場合に、単数と複数の両方に定義された同じメッセージIDを持つpoファイルが処理されるようになりました
• Helper::addClass()は、クラス属性が配列の場合、警告を出力しなくなりました
  • 今まではクラス属性が配列で来た場合 trim に渡ったタイミングで警告が出ていたようです
• Viewのsetterはvoidではなく$thisを返却します
• RedisEngineでキャッシュを使用するケースにおいて、Cake\Cache\Cache::incrementやCake\Cache\Cache::decrementを使用する際に、durationを0に設定している場合はtimeoutを設定しないようにしました
  • durationが0の時は確かにexpireを設定する必要はないですね！
• HtmlHelper::link()は、fullBaseオプションをサポートするようになりました
• Text::uuid()は、random_intが定義されていればrandom_intを使用するようになりました
  • 定義されていない場合は従来通りのmt_randが使用されます
• Debugger::highlight()が1行ずれてハイライトされない不具合が修正されました
  • Cookbookのこのあたりのお話ですね。今まではhighlight対象なのがfileの行数-1されていたのでずれてハイライトされる不具合があったようです
• Http\Client::addCookie()で追加されたCookieには、パスとドメインが必要です

実はコントリビューターになりました

Bakery(CakePHPの公式ブログ)に名前が載りました！やった〜。

修正は先程ご紹介した変更点の1つ目のものです。 実はコネヒトからコントリビューターがでるのは田村(@Utmrer)に引き続き2人目です。 今回は、すごく気合を入れて「よし！なにかOSSに貢献するぞ！！！」と思い立ってIssueを洗いPRを送ったわけではありません。自分が実装している途中に「おや？これはもしかして」と思い、チーム内reviewをしてもらって勇気を出してPRを送ってみました。

いままでOSSにPRを送った経験がなかったので、「こんな些細な事で送っていいのかな？」「英語理解してもらえるかな？」「英語でマサカリとんできそう…」と少し尻込みする気持ちが無かったわけではありません。 ですが、勇気を出しておくってマージされた瞬間に「あ、よかったな。これからも少しでも使っているOSSに貢献していきたいな」という気持ちが湧いてきたので、どんな小さな変更でも、取りあえずPRしてみることをおすすめします！ また、意外と拙い英語でも受け入れてもらえるのだなとわかったことも、今後別のものにもチャレンジしてみようと思えたので、私にとって大きい収穫でした。 また、今回の修正箇所はCookie関連の場所だったので、改めて現在のCookieプロパティ関連の知見を深め、復習することができました。

社内にはCakePHPだけでなく、さまざまな言語やOSSへ精力的に貢献している仲間がいるので、今後も良い刺激を受けつつちょっとずつ普段自分が使用しているツール等に恩返しをしていけたらとても素敵だな、と思いました。(ちなみに、はじめて記念としてPRのページはブックマークしました :innocent:)

ありがとうって言ってもらえてとっても嬉しかったです(*´ڡ`●)

おわりに

CakePHPアップデート連載、今回はちょっとしたお気持ちを添えた投稿となりましたがいかがだったでしょうか。 次回は最近CakePHPプラグインを作成していた弊社エンジニアいとしょ(@itosho) がお送りいたします！！

CakePHP3.5.1にアップデートしました！

こんにちは〜。先の投稿では幽☆遊☆白書を読んだと書きました、あれから少し日が空いたのですがその間にONE OUTSを読んだ次第です金城 (o0h_)です。
主人公がエゲツない天才で大活躍〜！って、やっぱり良いもんですね！！

[まとめ買い] ONE OUTS（ヤングジャンプコミックスDIGITAL）

さて、気づいたらCakePHPは3.5時代に突入！！しておりまして、
コネヒトでは3.4.12→3.5.0 →3.5.1へとアップデートを完了させております。
※ to 3.5.0は @itosho がやってくれました 💯

今回のエントリーでは、

1. 個人的に3.5.0で入った気になるトピック
2. 3.5.1のアップデート差分のおさらい

をしてみようと思います。！

CakePHP3.4.12にアップデートしました！

こんにちは、最近になって幽☆遊☆白書を読了した金城 (o0h_)です。
やはり 危機感 は大事だなと思いました。。それがある人から見ると、それのない人については「分かる」ってことですよね。しっかりと視座を上げて生きていかなければなりません。抜かりのない人間になりたい。

前回のアップデートから少し間が空いてしまいましたが・・>< またまたCakePHPのアップデートを行いました。

Kotlin開発Tech Talksで登壇してきました

こんにちは！

こんにちは！富田(@tommykw)です。 先日、株式会社葵さん、ChatWorkさん、m-gramさん、エウレカさんと5社合同のKotlin勉強会があり、Kotlin導入についての発表させていただきましたので、共有させていただきます。

Kotlin開発Tech Talksとは

connpass.com

5社では共通点としてヒトをつなぐサービスを展開しており、5社共にKotlinを導入しています。Kotlin導入度合い、開発リソース、会社規模も異なる環境下で、それぞれのKotlinのノウハウ、知見を共有するための勉強会でした。上記リンクより、登壇者の方のスライドを閲覧できますので、良かったらご覧ください。

発表内容

speakerdeck.com

私はコネヒトにジョインして約10ヶ月間、Kotlinの導入、運用を行い、その中で得たKotlinとJavaの相互運用についての情報を共有させていただきました。当時を振り返ると、エイヤ！と導入していた部分も少なからずあり、反省点も多かったのですが、改めてそれらを振り返る良いきっかけとなりました。

最後に

プロダクトへのKotlin導入からテストへのKotlin導入など、実際の業務に関わるノウハウ、知見の共有が有難かったですし、特にKotlin未経験者に対してレビューを手厚くしたり、Kotlin未経験者のサポートなどチーム全体でKotlin力を上げるお話は興味深かったです。全体を通して、Kotlinが公式サポートされて導入の機運がますます高まってきていると思いますが、一方でKotlinとJavaの相互運用の難しさがあるという印象でした。有意義な時間を過ごせました！みなさんありがとうございました！

【資料公開】コネヒトが考えるサービスづくりに必要な技術とその考え方について

こんにちは！

CTOの島田(@tatsushim)です。 先日「【TECH PLAY Career Meetup】活躍しているフルスタックエンジニアが語る！サービスづくり勉強会」に登壇させていただきました。 techplay.jp 当日の発表の後で「スタートアップでサービスをつくる上で大事なことが学べて良かった」というお声と資料公開の要望をいただきましたので、こちらで共有させていただきます。

発表内容

今回の勉強会では「フルスタックエンジニア」がキーワードでしたが、良いサービスを作るための必要条件はすべての技術に精通することではないというお話をさせていただきました。 それは、コネヒトは明確に技術の目的を「ユーザーのために良いサービスをつくること」 としているからです。 目的達成のために、コネヒトでは以下の3つが大事だと考えています。

コネヒトが大事にしている3つのこと

• 技術を手段として認識していること
• 知らないことを「知らない」と正しく認識して任せること
• サービスと共に成長できる柔軟さを持つこと

発表資料

詳細な内容についてはぜひ以下の発表資料をご覧いただければと思います。

終わりに

ついついプログラマとして手を動かしてしまいがちですが、ときには「つくらない」という選択肢を持つことがアウトプットの最大化に繋がるかもしれません。

島田(@tatsushim)がお送りしました！

開発環境改善としてDockerを導入した話

こんにちは。 5月よりコネヒトにjoinしたインフラエンジニアの永井(shnagai)です。

コネヒトにjoinして最初のタスクで、開発環境改善として一部のサービスにDockerを導入しました。 今回は、開発環境改善の道筋とそこから得られたDocker周りの知見について共有します。

開発環境で解決すべき課題

まずは、開発環境改善を行うにあたり、現状の環境の課題を明確にしました。 vagrantで開発環境を組んでいるとありがちな課題がコネヒトの環境にもありました。

1. 開発環境が不安定

vagrant環境が壊れる。。 突然VMが不調になりそれを直すために1~2時間持っていかれたり、 Aさんの環境でしか起きない再現不能の不具合が起きたり、 本来割くべき開発への時間が開発環境を直すことに費やされていました。。

2. アプリケーション増加によるホストOSの負荷問題

macで4,5,6個VM立てると重すぎて。。 サービス数が増える度に、VMの数が増えていきホストマシンのmacのリソースが限界を迎えていました。

3.本番/開発環境の乖離

初回に作成したVagrantのboxファイルを固定して使っていた関係で、 boxの中身はブラックボックスになりメンテナンスもほぼされていない状態でした。 本番との乖離は認識しているけど、追いつかせるのが面倒だし何が正しいかもいまいち不明瞭でした。

理想の開発環境

技術選定するにあたり、開発環境の理想の姿を定義しました。

• 開発者はコマンド一つくらいのレベルで、さっとローカル環境を立ち上げる事が出来る
• 誰でも同じ環境が立てられる(開発者/デザイナー関係なく)
• 設定ファイルがgit管理されておりブラックボックスがない(ミドルウェア,OS,プラグインのバージョンも設定ファイルで管理)
• 本番も同じ設定ファイルから作られたイメージがデプロイされ、開発環境と本番環境に全く差異のない状態

この理想の状態を実現出来るツールは、今のところDocker一択という話になり、Dockerの導入を前提として開発環境の改善を進める事にしました。

Docker導入の進め方

「新しいツールを入れる時は小さく始める」という原則に基づき、下記のような流れで実際の導入を進めました。

まずは、手元で動く環境を作る
↓
特定のメンバ(1,2名)にパイロット協力してもらい膿を出し切る
※パイロットメンバの協力が絶対不可欠
※いきなり全体展開は絶対ダメ(開発止まる。。。)
↓
ハンズオン形式で全メンバに概要説明した後Docker環境を手元に作ってもらう
↓
Docker関連の問題が出た時はすぐにキャッチアップして潰していく

アーキテクチャ

技術的TIPS

ここからは、Docker for Mac + docker-composerで開発環境を組む上で得られた知見をTIPS集的に書きます。

docker-composeで楽にコンテナ起動

docker-composeというと、複数のコンテナを一括で立ち上げれるという事がよく言われるメリットですが、 今回は、コンテナ操作のコマンドを容易に出来るという点に注目してdocker-composeを導入しました。

例えば、コンテナを立ち上げる時に

docker-composeだとymlに定義することで下記のコマンドでコンテナが簡単に起動出来ます。

※ -dはバックグラウンド起動

$ docker-compose up -d 

version: '3'
services:
  sample1:
    container_name: sample1-web
    build: .
    ports:
      - "8080:80"
    volumes:
      - .:/var/www/html:cached
    environment:
      LANG: ja_JP.UTF-8
      TZ: Asia/Tokyo
    command: bash -c "cd /var/www/html && sh docker-init-setup.sh && /usr/sbin/httpd -DFOREGROUND"
networks:
  default:
    external:
      name: sample_link

Dockerコマンドだと、毎回ポートマッピングやらコンテナ/イメージ名を意識しなければなりません(面倒くさい)

$ docker run -d -p 8080:80 -name sample1-web [イメージ名] 

日々使う開発環境では、コンテナを直感的に操作出来る事は重要だと思うのでこれはメリットだなと感じています。

コンテナ同士の通信

ホスト-コンテナ間の通信はポートマッピングしたポートで通信可能ですが、コンテナ間で直接通信したケースもあります。 そんな時は、docker-networkでユーザ定義NWを作り、そのNWにコンテナを参加させてあげます。

docker-networkの作成

## network作成
$docker network create --driver bridge sample_link

## 確認
$docker network ls|grep mamari_link
54528e6eacf6        sample_link                 bridge              local

コンテナ起動時に、networkを明示的に指定してあげる事で、同一docker-networkに存在するコンテナ同士はコンテナ名で通信する事が可能になります。

docker-composeの場合は、ymlに下記のように定義

networks:
  default:
    external:
      name: sample_link

dockerコマンドの場合は、下記のように --netオプションを使用

docker run -d --net=sample_net

Docker for Mac遅すぎる問題

Docker for Macは、MacのHyperkitという仮想マシンレイヤ(linux)を使って、シームレスにDockerをMac上で動かすものですが、このHyperKit経由でのディレクトリマウントが遅い問題が出ました。

これは、Docker for Mac の17.05以降でサポートされた、VOLUMEのcachedオプションで回避しました。

たいてい開発環境だと、ホストでコードをいじりつつコンテナ上のwebアプリで動作確認をするというパターンかと思います。cachedと聞くと時間差がありそうで少し不安になりますが、今のところ同期が遅いというような声は聞こえてきていませんので問題なく動いています。(Docker for Mac Edgeの17.05でたまに同期されない問題が出たので、17.06 stableに上げたところ解決しました)

    volumes:
      - .:/var/www/html:cached

今だと、Docker for Macの17.06がstableなので、そちらを使うとcachcedオプションが使えます！！

DockerコンテナからVirtualMachineへの通信がたまに途切れる問題

これが、一番頭を悩ませた問題なのですが、コンテナからVM上に立っているredisに対して通信をしていたのですが、たまにredisと通信が出来なくなるような事象が発生しました。

実際に、redis-cliを使って計測した結果が下記です。

アベレージは、0.72sなのにたまに45sの通信が発生。これにあたるとアプリが異常に遅くなるという事象でした。。

$ docker exec redis redis-cli --latency -h 192.168.33.200 -p 6379
min: 0, max: 45, avg: 0.72 (11446 samples)

redisをコンテナで立てて、同じ試験をした結果抜群の安定感を確認。

$ docker exec redis redis-cli --latency -h docker-redis -p 6379
min: 0, max: 3, avg: 0.21 (10061 samples)

最終的な原因まではわからなかったのですが、dockerコンテナからVMへの通信は、ホストマシン間で複数のブリッジNWを経由して行われるので、不安定になることがありそうです。素直にDockerコンテナに集約してあげた方がいいかもしれません。

さいごに

Dockerfileはインフラの持ち物でなく、みんなで育てていきたい

という気持ちが開発者に伝わり、自分で新サービスdockerで作り始めるメンバがいたり、すぐにDockerfileの修正点指摘してくれたりコード化されたメリットを早くも感じ始めています。

Vagrant構成で苦しんでいる方がいれば、そんなに障壁は高くないのでまずは1サービスから小さくDocker導入を進めてみればいかがでしょうか?

コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com

CakePHP3.4.8にアップデートしました！

こんにちは。最近は妄想キャリブレーションの『桜色ダイアリー』をヘビロテしているサーバーサイドエンジニアの@itoshoです。

既に3.4.9がリリースされていますが（汗）、先週3.4.8がリリースされましたので、今回も簡単にアップデート内容をまとめさせていただきました。

CakePHP3.4.8の変更点まとめ

今回は以下の変更がありました。

• composerのkeywordsが改善されました。
• BelongsToMany::link()関数で複数の操作が正しく持続されない不具合が修正されました。
• APIドキュメントが改善されました。
• POファイル解析で同じメッセージキーが定義されている時、コンテキストの有無を問わずメッセージが正しく解析出来るように修正されました。
  • この変更により、翻訳メッセージの内部データが変更されるため、アップグレードする際はi18nキャッシュデータを消去する必要があるようです。
• ValidationRuleでunpack errorが発生する不具合が修正されました。
• RouteBuilder::prefix()関数でpathセグメント（prefix routing scopeに使用される）をカスタマイズ出来るようにするためのpathオプションがサポートされました。
• LoggingでentityのJSONエンコードバージョンがログに記録されるように修正されました。
  • さらにログに記録されたJsonSerializableインスタンスは、Unicodeデータをエンコードしないようです。
• 他のQuery::matching()関数の中で呼び出されたQuery::matching()関数を使用するページネーションクエリが無効なSQLを発行する不具合が修正されました。
• AngularJSによって生成されたURLが正しくパースされない不具合が修正されました。
• MailerでEmail上でのgetter関数が正しくプロキシされない不具合が修正されました。
• Database\Query::clause()関数が不明なクラスを読み込んだ際にexceptionが発生するよう修正されました。
• RedisEngine::add()関数はキーを2回書く代わりに、setTimeout()を使ってTTLを出来るようになりました
• RedisEngine::increment(), decrement()関数はカウンターでTTLをセット出来るようになりました。
  • Memcachedのカウンターと一貫した動作になったようです。
• Zを使ったISO8601形式の日付データが正しくパースされない不具合が修正されました。
• ProgressHelper::init(), draw(), increment() 関数は$thisを返却するようになりました。
• Auto Incrementが明示的に無効になっている場合、MySQLスキーマのリフレクションによって、主キーのカラムが自動的にインクリメントされなくなりました。
• FormHelper::radio()関数で、オプションが複合フォームで定義され、オプションのサブセットのみがdisabled属性になっている場合に、disabled属性が正しく生成されない不具合が修正されました。
• TableHelper::output()関数で全ての行が同じキーを持つ必要がなくなりました。

詳細は公式のリリースノートをご覧ください。

また、リリースノートには記載されておりませんが、先日界隈で話題になった ServerRequestFactoryクラス内のextract()関数が予期せぬ不具合を引き起こす可能性がある問題*1も修正されております。スピード感素晴らしいですね！

アップデート時にやったこと

リリースノートの項目自体は多かったものの、弊社のプロダクトに影響がありそうな変更はなかったため、今回も composer updateコマンドを実行後、CIが通っていればOKとして、リリースを行いました。 （リリース後も特に問題は発生しておりません）

おわりに

この冴えない連載も気付けば4回目の更新になりました！更にこの連載を育てるべく次回の更新は弊社Superエンジニア@super_mannerがお届けします！

脚注

*1:CakePHP 3.4.7 にあげようとしたら思わぬところでハマったので、それが設定ファイルだったとしても変数名はちゃんと考えてつけましょう、という話。