こんにちは〜。先の投稿では幽☆遊☆白書を読んだと書きました、あれから少し日が空いたのですがその間にONE OUTSを読んだ次第です金城 (o0h_)です。
主人公がエゲツない天才で大活躍〜！って、やっぱり良いもんですね！！
![[まとめ買い] ONE OUTS（ヤングジャンプコミックスDIGITAL）](https://images-fe.ssl-images-amazon.com/images/I/B1D0kghRHFS._SL160_.png "[まとめ買い] ONE OUTS（ヤングジャンプコミックスDIGITAL）")
[まとめ買い] ONE OUTS（ヤングジャンプコミックスDIGITAL）
さて、気づいたらCakePHPは3.5時代に突入！！しておりまして、
コネヒトでは3.4.12→3.5.0 →3.5.1へとアップデートを完了させております。
※ to 3.5.0は @itosho がやってくれました 💯
今回のエントリーでは、
をしてみようと思います。！
こんにちは！富田(@tommykw)です。 先日、株式会社葵さん、ChatWorkさん、m-gramさん、エウレカさんと5社合同のKotlin勉強会があり、Kotlin導入についての発表させていただきましたので、共有させていただきます。
5社では共通点としてヒトをつなぐサービスを展開しており、5社共にKotlinを導入しています。Kotlin導入度合い、開発リソース、会社規模も異なる環境下で、それぞれのKotlinのノウハウ、知見を共有するための勉強会でした。上記リンクより、登壇者の方のスライドを閲覧できますので、良かったらご覧ください。
私はコネヒトにジョインして約10ヶ月間、Kotlinの導入、運用を行い、その中で得たKotlinとJavaの相互運用についての情報を共有させていただきました。当時を振り返ると、エイヤ！と導入していた部分も少なからずあり、反省点も多かったのですが、改めてそれらを振り返る良いきっかけとなりました。
プロダクトへのKotlin導入からテストへのKotlin導入など、実際の業務に関わるノウハウ、知見の共有が有難かったですし、特にKotlin未経験者に対してレビューを手厚くしたり、Kotlin未経験者のサポートなどチーム全体でKotlin力を上げるお話は興味深かったです。全体を通して、Kotlinが公式サポートされて導入の機運がますます高まってきていると思いますが、一方でKotlinとJavaの相互運用の難しさがあるという印象でした。有意義な時間を過ごせました！みなさんありがとうございました！
CTOの島田(@tatsushim)です。 先日「【TECH PLAY Career Meetup】活躍しているフルスタックエンジニアが語る！サービスづくり勉強会」に登壇させていただきました。 techplay.jp 当日の発表の後で「スタートアップでサービスをつくる上で大事なことが学べて良かった」というお声と資料公開の要望をいただきましたので、こちらで共有させていただきます。
今回の勉強会では「フルスタックエンジニア」がキーワードでしたが、良いサービスを作るための必要条件はすべての技術に精通することではないというお話をさせていただきました。 それは、コネヒトは明確に技術の目的を「ユーザーのために良いサービスをつくること」 としているからです。 目的達成のために、コネヒトでは以下の3つが大事だと考えています。
詳細な内容についてはぜひ以下の発表資料をご覧いただければと思います。
ついついプログラマとして手を動かしてしまいがちですが、ときには「つくらない」という選択肢を持つことがアウトプットの最大化に繋がるかもしれません。
島田(@tatsushim)がお送りしました！
こんにちは。 5月よりコネヒトにjoinしたインフラエンジニアの永井(shnagai)です。
コネヒトにjoinして最初のタスクで、開発環境改善として一部のサービスにDockerを導入しました。 今回は、開発環境改善の道筋とそこから得られたDocker周りの知見について共有します。
まずは、開発環境改善を行うにあたり、現状の環境の課題を明確にしました。 vagrantで開発環境を組んでいるとありがちな課題がコネヒトの環境にもありました。
vagrant環境が壊れる。。 突然VMが不調になりそれを直すために1~2時間持っていかれたり、 Aさんの環境でしか起きない再現不能の不具合が起きたり、 本来割くべき開発への時間が開発環境を直すことに費やされていました。。
macで4,5,6個VM立てると重すぎて。。 サービス数が増える度に、VMの数が増えていきホストマシンのmacのリソースが限界を迎えていました。
初回に作成したVagrantのboxファイルを固定して使っていた関係で、 boxの中身はブラックボックスになりメンテナンスもほぼされていない状態でした。 本番との乖離は認識しているけど、追いつかせるのが面倒だし何が正しいかもいまいち不明瞭でした。
技術選定するにあたり、開発環境の理想の姿を定義しました。
「新しいツールを入れる時は小さく始める」という原則に基づき、下記のような流れで実際の導入を進めました。
まずは、手元で動く環境を作る ↓ 特定のメンバ(1,2名)にパイロット協力してもらい膿を出し切る ※パイロットメンバの協力が絶対不可欠 ※いきなり全体展開は絶対ダメ(開発止まる。。。) ↓ ハンズオン形式で全メンバに概要説明した後Docker環境を手元に作ってもらう ↓ Docker関連の問題が出た時はすぐにキャッチアップして潰していく
ここからは、Docker for Mac + docker-composerで開発環境を組む上で得られた知見をTIPS集的に書きます。
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にコンテナを参加させてあげます。
## 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は、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
これが、一番頭を悩ませた問題なのですが、コンテナから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で作り始めるメンバがいたり、すぐにDockerfileの修正点指摘してくれたりコード化されたメリットを早くも感じ始めています。
Vagrant構成で苦しんでいる方がいれば、そんなに障壁は高くないのでまずは1サービスから小さくDocker導入を進めてみればいかがでしょうか?
コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。
こんにちは。最近は妄想キャリブレーションの『桜色ダイアリー』をヘビロテしているサーバーサイドエンジニアの@itoshoです。
既に3.4.9がリリースされていますが（汗）、先週3.4.8がリリースされましたので、今回も簡単にアップデート内容をまとめさせていただきました。
今回は以下の変更がありました。
BelongsToMany::link()関数で複数の操作が正しく持続されない不具合が修正されました。ValidationRuleでunpack errorが発生する不具合が修正されました。RouteBuilder::prefix()関数でpathセグメント（prefix routing scopeに使用される）をカスタマイズ出来るようにするためのpathオプションがサポートされました。LoggingでentityのJSONエンコードバージョンがログに記録されるように修正されました。
Query::matching()関数の中で呼び出されたQuery::matching()関数を使用するページネーションクエリが無効なSQLを発行する不具合が修正されました。MailerでEmail上でのgetter関数が正しくプロキシされない不具合が修正されました。Database\Query::clause()関数が不明なクラスを読み込んだ際にexceptionが発生するよう修正されました。RedisEngine::add()関数はキーを2回書く代わりに、setTimeout()を使ってTTLを出来るようになりましたRedisEngine::increment(), decrement()関数はカウンターでTTLをセット出来るようになりました。
Zを使ったISO8601形式の日付データが正しくパースされない不具合が修正されました。ProgressHelper::init(), draw(), increment() 関数は$thisを返却するようになりました。FormHelper::radio()関数で、オプションが複合フォームで定義され、オプションのサブセットのみがdisabled属性になっている場合に、disabled属性が正しく生成されない不具合が修正されました。TableHelper::output()関数で全ての行が同じキーを持つ必要がなくなりました。詳細は公式のリリースノートをご覧ください。
また、リリースノートには記載されておりませんが、先日界隈で話題になった ServerRequestFactoryクラス内のextract()関数が予期せぬ不具合を引き起こす可能性がある問題*1も修正されております。スピード感素晴らしいですね！
リリースノートの項目自体は多かったものの、弊社のプロダクトに影響がありそうな変更はなかったため、今回も composer updateコマンドを実行後、CIが通っていればOKとして、リリースを行いました。
（リリース後も特に問題は発生しておりません）
この冴えない連載も気付けば4回目の更新になりました！更にこの連載を育てるべく次回の更新は弊社Superエンジニア@super_mannerがお届けします！
こんにちは、サーバーサイドにコードを放り込んでいます金城 (o0h_)です。
週に数回の頻度で「はじめてのメーガン・トレイナー」を聴いています。 まったりする〜
ここのところ、弊社では「社内でエンジニーアズのLTしよーぜ！」をしています。
私も発表する機会があったので、CakePHP3の紹介トークのようなものをしました。
特に「2.xなら触ったことがある！」ような人を意識した内容にして、2.x→3.xの最も目覚ましい変化の1つである「ORM/モデルレイヤーの(大)変革！！」を取り上げました。様々な変更内容がある中、フォーカスしたのは「PHPとデータベース間の、データ形式の変換の流れ」についてです。1
その際に質問を受けたり、自分でも「今までそんなに気にしていなかったかもなー？」という点がいくつか湧いてきました。
今回は、LTを行った内容をベースとしながら、私なりに「CakePHP3のモデルについて」改めて調べた内容を交えて紹介してみたいと思います。
主に前メジャーバージョンである2.xとの比較を意識しながら進めて参ります。
過去にQiitaにも晒した内容の焼き直しとなりました。社内的に「CakePHP3に触れる面子が増える」という事情があったので、改めて紹介しておくか〜と思ったのが動機です。↩
