コネヒト開発者ブログ

コネヒト開発者ブログ

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に触れる面子が増える」という事情があったので、改めて紹介しておくか〜と思ったのが動機です。

続きを読む

今からちょっとだけ先の未来、CakePHP4の話 〜Upcoming CakePHP Roadmap & Releases〜

こんにちは、森の蒸留所に行ってからずっとウイスキー飲みたい金城 (o0h_)です。
今回は、ちょっと小ネタを・・・

次世代のCakePHPの姿が、少しずつ。

先日CakeFestというCakePHPの公式カンファレンスが行われました。

その中でMark Story氏によってCakePHPのロードマップについての講演があったのですが、
私はそれを「未来だ、未来だ!!」と思ってワクワクしながら眺めていたわけです。

www.pscp.tv

さて、その内容が先程Bakeryにアップされました!! 🎉🎉
普段めっきりCakePHP3にお世話になっている弊社エンジニアとしては、この興奮を社(内|外)に少しでも早くおすそ分けしたいな‥?と思うのです。

そこで、本エントリーではBakeryで触れられている内容(+α)を簡単に紹介させてください。

ざっくり言うと

  1. 3.5はこの夏にリリースされる予定だよ。後方互換性はもちろんあるけど、廃止予定なAPIはランタイムエラーを吐くようにするよ
  2. 4.0は2017年の遅くか、2018年にリリースされる予定だよ。PHP7.1+を要求するけど、3.6を使っていれば簡単に移行できるようにするよ(&& 2.x系->3.0のような劇的な変化はしない!)
  3. 3.x系については、4.0.0が出た後18ヵ月はバグ対応をして36ヵ月はセキュリティ対応をする予定だよ
  4. 2.x系については、バグ対応:12ヵ月、セキュリティ対応:18ヵ月を予定しているよ

という内容でしょうか。
ぜひ 原文 を御覧いただきたいです!

姿を見せつつある4.0

Strawberry って言うのですねw 可愛い。1
コンセプトとしての4.0は、 こちらのスライドを是非ご一読ください。

www.slideshare.net

弊社では3.x系と2.x系のプロダクトが混在しているので、どちらも日常的に読み書きしていますが
3.xは書いていて「とても気持ち良いな」と感じています。お気に入り。

・・・とはいえ、2.x系 > 3.0では「非常に劇的」な変化があり、身体感覚に馴染むまでに大きな学習コストと時間を要したのは事実です。。
そのため、「3.6からの移行ハードルを下げる」というのはとても興味深く感じました。2

具体的には「非推奨のものを使っていなければ、ちょっとの手間で動く!」と明記されているので、
こうなると気の重さよりもワクワク感が大きくなってきますよね。

また、「厳密な型制約」についても言及されていて、この点も個人的に非常に目を引かれています。3

PHP全体で言える傾向として、 「簡単に書ける」の意味合いが「間違えても動く」から「間違いにくくなる」にどんどんシフトして行っていると感じる今日このごろです。
その文脈に則って、CakePHP4.0において「ますます今っぽく」なるのかな、という印象を受けます。

さて機能から見る4.0は、一体どんな姿になるのか?についてですが、当該のエントリーではあまり詳しく触れられていません。
気になる方は、4.0 Roadmap · cakephp/cakephp Wiki · GitHubをウォッチしてみてください!

4.0を見据えた3.6

3.6が、実質「3.x系の最後の進化」になるのかもしれません。4

そしてコレも「4.0への移行を簡単にしたいため!」という理由からだそうなので、位置づけとして「橋渡し」的な面があるのかと理解しています。

その3.6ですが、機能的には「Middlewareレイヤーの強化をする!!」というのが個人的な関心でありつつ
もしかすると、それよりも「非推奨のものを使うとランタイムエラーを吐く」というのに目を引かれました。すげぇな。。。5

次点として、「ルーティングを書きやすく」も便利そうだなぁ〜と思っています。 issue#10643を見ると、 例えば/users/:name/users/{name}となっていくのでしょうか。 これは今までよりも直感的だなと思います!6

今後の動向に注目 && 日頃から備えておく

個人的な感覚では、3.0が出たのは割と最近・・・とも思っていたのですが。。
もう具体的な「4.0」の声が聞こえてきつつあります。
どんな面白いコードやエレガントな機能が出てくるかな?と今から楽しみです。
もう少ししたら、次世代CakePHPの開発もいよいよ加速していくと思いますので、これは目が離せません!

また、今回のマイグレーションやそのサポートに関する指針を見て、
改めて「レガシー化させないための最大の武器は、小さなホコリは気付いたら払っておく」ことだと思いました。
弊社では方針として「なるべく最新に追従する」戦略をとってマイナーアップデートも積極的に行っています。
これは、小さな修正でも溜め込んでいくと「移行」自体が一大プロダクトになってしまうことへの恐怖からです。。。 開発の本分は「価値を提供する、サービスを育てる」点だと思っていますので、それ以外の心労や障壁は排除しておきたいものですね!

引き続き、必要な情報を適切に摂取しながら、PHPやプログラミングを楽しんでいけたらな〜と思います!


  1. ちなみに3.xは Red Velvetです。

  2. Lastly, an explicit goal is to make the upgrade easy. と記事中で述べられています。

  3. All currently documented types will be converted into strict typehints where possible. とのこと

  4. This would make 3.6 the last 3.x with the possibility of 3.7 happening. だそうで!

  5. 全くの余談ですが、先日行われたPHPカンファレンス福岡での@hirakuさんの発表を聴いて「もっと上手くerrorを使えば開発の高速化・安心化ができるのかもなぁ」と反省したところでした。CakePHPが「phpdocだけでなくランタイムエラーを吐かせる」という課題に対してどのように取り組んで行くのかは興味深いです。
    cf: PHPのエラーと例外再入門 / php-error-and-exception // Speaker Deck

  6. 「記法がシンプルっぽいやつに」は単なる一例で、それよりも強烈に「コンセプトレベルでの変更」と言えるような機能強化が予定されていると感じています。ぜひ当該Issueの議論を眺めてみてください!