コネヒト開発者ブログ

コネヒト開発者ブログ

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

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

さて、気づいたら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のアップデート差分のおさらい

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

https://cdn-ak.f.st-hatena.com/images/fotolife/i/itosho525/20170430/20170430222524.jpg

続きを読む

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

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

前回のアップデートから少し間が空いてしまいましたが・・>< またまたCakePHPのアップデートを行いました。 https://cdn-ak.f.st-hatena.com/images/fotolife/i/itosho525/20170430/20170430222524.jpg

続きを読む

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

f:id:tommy_kw:20170727102131j:plain

こんにちは!

こんにちは!富田(@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の相互運用の難しさがあるという印象でした。有意義な時間を過ごせました!みなさんありがとうございました!

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

f:id:tatsushim:20170718232036j:plain

こんにちは!

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関連の問題が出た時はすぐにキャッチアップして潰していく

アーキテクチャ

f:id:nagais:20170705162026p:plain

技術的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導入を進めてみればいかがでしょうか?

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

f:id:itosho525:20170430222524j:plain

こんにちは。最近は妄想キャリブレーションの『桜色ダイアリー』をヘビロテしているサーバーサイドエンジニアの@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がお届けします!

脚注

CakePHP3のORMの中核を担う「Entity」とは何か 〜CakePHP2ユーザー向けに〜

こんにちは、サーバーサイドにコードを放り込んでいます金城 (o0h_)です。

https://cdn.mamari.jp/authorized/594fc0f8-f2e8-49c7-a174-2ce30a0103ab.jpg

週に数回の頻度で「はじめてのメーガン・トレイナー」を聴いています。 まったりする〜


ここのところ、弊社では「社内でエンジニーアズのLTしよーぜ!」をしています。
私も発表する機会があったので、CakePHP3の紹介トークのようなものをしました。

特に「2.xなら触ったことがある!」ような人を意識した内容にして、2.x→3.xの最も目覚ましい変化の1つである「ORM/モデルレイヤーの(大)変革!!」を取り上げました。様々な変更内容がある中、フォーカスしたのは「PHPとデータベース間の、データ形式の変換の流れ」についてです。1

その際に質問を受けたり、自分でも「今までそんなに気にしていなかったかもなー?」という点がいくつか湧いてきました。
今回は、LTを行った内容をベースとしながら、私なりに「CakePHP3のモデルについて」改めて調べた内容を交えて紹介してみたいと思います。
主に前メジャーバージョンである2.xとの比較を意識しながら進めて参ります。


  1. 過去にQiitaにも晒した内容の焼き直しとなりました。社内的に「CakePHP3に触れる面子が増える」という事情があったので、改めて紹介しておくか〜と思ったのが動機です。

続きを読む