こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ - Apps on Google Play You can realize "online medical experience" from online medical treatment / medication instruction to drug delivery with this one app. play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 play.google.com play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ - Apps on Google Play You can realize "online medical experience" from online medical treatment / medication instruction to drug delivery with this one app. play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ - Apps on Google Play You can realize "online medical experience" from online medical treatment / medication instruction to drug delivery with this one app. play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ - Apps on Google Play You can realize "online medical experience" from online medical treatment / medication instruction to drug delivery with this one app. play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 8/25 に行われた、日本初(!!)の Kotlin の言語カンファレンスである Kotlin Fest 2018 に弊社は”ひよこスポンサー”として協賛させていただきました。 公式 Twitter で紹介された様子 スポンサーのご紹介です。Medley ( @medley_life ) 様に Kotlin Fest のひよこスポンサーになっていただきました！よろしくお願いします！ #kotlinfest https://t.co/RojsiqlGMi — Kotlin Fest (@kotlin_fest) August 24, 2018 今回スポンサーチケットで参加させていただいたので、つれづれとレポートを書いてまいります。 メドレーと Kotlin の関わり なぜ、メドレーが Kotlin Fest に協賛したかというと Kotlin を使って Android アプリを作っているからになります。 オンライン診療アプリ CLINICS の Android 版で使っています。 CLINICS(クリニクス)　オンライン診療・服薬指導アプリ - Apps on Google Play You can realize "online medical experience" from online medical treatment / medication instruction to drug delivery with this one app. play.google.com Android で正式に Kotlin サポートすることが アナウンス されてからできるところを Java から Kotlin に書きかえていっています。 方針としては、ムリに全部のソースを Kotlin にするという形ではなく改修などで触ったソースで余力があれば書きかえるというスタンスでやっていますが、それでも現在 50%弱のソースが Kotlin になっています。 Kotlin で書いた場合に Java よりも可読性や堅牢性が上がるというメリットを実感していたところ、今回の Kotlin Fest の開催を知り、協賛させていただいたという次第です。 イベントの様子 会場は 東京コンファレンスセンター品川 でした。自分は初訪問だったのですが、設備も充実しており良い会場だと思いました。 無限に出てくるかのようなコーヒー・飲み物とお菓子が大変ホスピタリティを感じさせます。 スポンサーブースも盛況で、なかでも Yahoo! Japan さんのモブプロ実演や、CyberAgent さんの Kotlin クイズなどが人気を集めていました。 M3 さんのブースでいただいたロゴ入りじゃがりこ セッション セッションは 2 セッションが同時に行われるという形式でした。 自分が参加したセッションのみですが簡単な感想でご紹介します。 Kotlin で改善する Android アプリの品質 Java から Kotlin への書きかえを考えた場合のアプリの品質を主軸にしてメリットを紹介する…というものでした。 Effective Java の中で紹介されている項目について、Kotlin ではどうなるかという視点での紹介は大変興味深かったです。 Kotlin は Java よりも Null 安全を始め、堅牢だというイメージがありましたが、こうして Java で するべきである という項目が Kotlin では言語仕様レベルで対応されていることが多いというのを目の当たりにすると、さらに頼もしく思えるというようなセッションでした。 Kotlin アプリのリファクタリングポイント Refactoring point of Kotlin application from Recruit Lifestyle Co., Ltd. 既に存在する Kotlin のコードをどのような指針でリファクタリングしていくかというセッションです。 「こういうときに書き方複数あるけどどうしよう…」という例ばかりだったので、自分達のアプリでもすぐに使えるような実践的なセッションでした。 中でもいかに Mutable なプロパティを避けるかというフローチャートは、理路整然としていてこれから Kotlin を書いていく上でかなり参考になりました。 Kotlin linter 自分の場合、JavaScript などでもわりと Linter は興味がある分野だったのですが、Kotlin の Lint について は android-lint しか使ったことがなかったので、紹介されている Linter の情報が参考になるセッションでした。 Kotlin の Linter もやはり AST を触らないとオリジナルルールの設定ができないのかーなど普段触れていなかった知識が得られて有意義でした。 が、Kotlin の AST は PsiViewer という IntliJ プラグインくらいしか対応してなさそうで、自分で設定するとなると若干つらそうだなという印象でした。 AST Explore あたりで気軽に試せると良いですね。 Kotlin で愛でる Microservices サーバサイド Kotlin を Microservice でガンガン使用するために必要なエッセンスがまとまったセッションでした。 元々使っていた Go との使いわけや、実際どのようなアーキテクチャで作って、デプロイや監視など運用をどのようにしているのかなどがコンパクトにまとまっていて大変分かりやすかったです。 サーバサイド Kotlin は弊社で使う予定は現状まだ無いのですが、このセッションを見た限りミニマムに始めることが可能な感じに思えたのが収穫でした。 まとめ Kotlin の日本初のカンファレンスでしたが、来場者もかなり多く Kotlin エンジニアの裾野が広いなという印象でした(セッションによっては立ち見も出ていました)。 またセッションも初級から上級まで幅広く取り揃えられていたので、飽きることなく楽しめましたし、来年以降も続いていってほしいと思ったカンファレンスでした。 メドレーでは今後も色々な Tech カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の楊です。メドレーの社内勉強会「TechLunch」で、前回は、 React の基本 を紹介しましたが、今回は HTTP Cache で、 医療介護求人サイト「ジョブメドレー」 のスピード改善ができないか検討した話について、共有しました。 なぜ HTTP Cache について話すことにしたのか ジョブメドレーには、医療機関や保育園、介護施設などさまざまな事業所の求人が掲載されています。現在、14 万を超える事業部の求人が掲載されており、かつ事業所側で求人原稿を修正することもできるため、求職者側が閲覧するスピードについては、いつも意識して改善に取り組んでいます。 その試行錯誤の中で、HTTP Cache を使って改善する方法について、実現性など含めて検証することにしました。 今回は、あるページをモデルケースに試してみました。このページは、PC は平均 250ms、モバイルは 180ms になっています。 ユーザが該当のページを見たときに「内容に更新がないときはブラウザ側のキャッシュを利用してスピードを最適化する」「ページが更新されていたら、最新の内容をすぐユーザへ反映する」という要件でスピード改善されることを目指すことにしました。 HTTP Cache とは？ Google Developers では以下のように説明されています。 ネットワーク経由で情報を取得するには時間もコストもかかります。レスポンスが大きいと、クライアントとサーバ間のラウンドトリップを何度も繰り返す必要があるため、レスポンスが利用可能となってブラウザで処理できるようになるまで時間がかかります。さらに、ユーザ側ではデータの通信コストが発生します。そのため、前に取得したリソースをキャッシュに保存して再使用できることは、パフォーマンスを最適化する上で非常に重要です。 この機能はほぼ全てのブラウザに対応しており、HTTP ヘッダーで CacheControl 、 ETAG 、 Last-Modified などを利用して、リソース更新するタイミングなどを細かくコントロール可能です。 Rails での HTTP Cache expire_in でキャッシュ 1 時間キャッシュしたい場合は、コントローラにコードを一行書けば大丈夫です。 expires_in ( 1 . hour ) これで問題なく 1 時間キャッシュされるのですが、「ページが編集されたら即時にユーザへ反映する」という要件を満たしてはいません。 ETAG を利用 では「ページが更新されたら最新の内容をすぐユーザへ反映して、更新がない時はブラウザ側のキャッシュを利用してスピードを最適化する」を行いたい場合はどうすればよいでしょうか。 ここでは ETAG を利用しようと思います。 ETAG はページの内容によって、ユニークな文字列を作成して、ブラウザ側でページの更新あるかどうかを判定するものです。 ETAG はどう作成されているか Rails のデフォルトでは HTTP Cache を有効になっていて、 ETAG を自動的に作成しています。 header[ 'ETag' ] = Digest::MD5 . hexdigest (body) 上のコードのようなイメージで、レスポンス Body から ETAG を作成します。 つまり、サーバから返される HTML ソースの内容が毎回同じであれば、ブラウザは前回キャッシュした内容を読み込むようになります。 サーバレスポンスタイムの短縮 今回の対象ページの機能としてサーバ側では主に二つの部分で時間がかかります。 DB、Redis などで画面表示が必要なデータ取得、ロジック処理 クライアントに返す HTML のレンダリング 対象ページは「HTML のレンダリング」する時間が長かったので、それを改善できれば、サーバレスポンスタイムを一気に短くできます。 画面に表示する必要なデータに変換がなければ、HTML のレンダリングをせずにレスポンスを返す機能がないかをさらに調べました。 fresh_when を使う 名前の通り、いつ画面更新するかをコントロールするメソッドです。 データベース中の該当データが更新されたら、新しい ETAG を作成するコードは以下のようになります。 fresh_when ( etag: [ @job_offer , @job_offer . facility ]) model から ETAG をどう作成するか model の cache_key から ETAG を作ります。 該当ページで使用する job_offer モデルの cache_key は "job_offer/5-20071224150000" のような感じになります。 model の id と updated_at の組み合わせでユニークな cache_key を作成しています。 Rails の該当コード def cache_key ( * timestamp_names ) case when new_record? " #{ model_name. cache_key } /new" when timestamp_names. any? timestamp = max_updated_column_timestamp (timestamp_names) timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " when timestamp = max_updated_column_timestamp timestamp = timestamp. utc . to_s (cache_timestamp_format) " #{ model_name. cache_key } / #{ id } - #{ timestamp } " else " #{ model_name. cache_key } / #{ id } " end end 自前の作成したクラスから ETAG をどう作成するか model だけではなく、自前で作成したクラスでデータ管理をしてるところもあります。 そちらでの実現方法も試してみました。 そこで ETAG を作るコードが Rails でどうなっているか追ってみました。 Rails の該当コード def retrieve_cache_key ( key ) case when key. respond_to? ( :cache_key ) then key. cache_key when key. is_a? ( Array ) then key. map { | element | retrieve_cache_key (element) }. to_param when key. respond_to? ( :to_a ) then retrieve_cache_key (key. to_a ) else key. to_param end . to_s end このように、自作クラスに cache_key のメソッドを定義したら、その結果から ETAG が作成されるようになっています。このメソッドを使って、ユニークな値を返せば大丈夫です。 ここまで調査したことを踏まえて、該当ページを HTTP Cache で実装をしてみました。以下が該当の疑似コードになります。 class JobOfferBrowsingHistory def cache_key # return job offer ids end end fresh_when に渡す @user_history = JobOfferBrowsingHistory . new fresh_when ( etag: [ @job_offer , @job_offer . facility , @user_history ]) テスト 開発環境で該当ページを 2 回ロードしました。 1 回目は 1200ms、キャッシュが効いた 2 回目は 130ms になりました。すごく早いです！ もちろん、ページ内のデータが更新されたら、最新の内容がページに反映されるようにもなっています。 これで「ページのデータが更新されたら、最新の内容をすぐユーザへ反映する」「更新がなければ HTTP Cache を返す」という状態が実現しました。 課題 実装ミスで、更新が必要なのに、更新されない問題が起こりえる 例えば、画面に新しい model を追加したが、 fresh_when に渡すのを忘れたとか 問題なく更新されることを保証する仕組みの実装 まとめ HTTP Cache を利用して、ジョブメドレーのスピード改善を検討してみた調査過程を紹介しました。 expire_in 、 ETAG の作成方法など色々調べて、最終的に fresh_when で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 https://www.wantedly.com/companies/medley

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の平木です。 去る 7/14(土)に Rails Developers Meetup 2018 Day 3 Extreme というイベントが開催されまして、 弊社の宍戸 が 電子カルテとセキュリティガイドラインと AWS と私 というタイトルで発表させていただきましたので、レポートさせていただきます。 発表のきっかけ 昨年に引き続き RubyKaigi 2018 で弊社 CTO の平山が LT スポンサーとして発表させていただいたり、ブースに出展をしていた ことがきっかけになり、Rails Developers Meetup の主催者である平野さん（ @yoshi_hirano )から平山へ出演のお声がけをしていただきました。イベントからイベントへ関係がつながるのはとても嬉しいですね。 発表テーマについて せっかく、お声がけしていただいたので、発表テーマも弊社の特色が出るものが良いであろうと決まったのが今回のテーマです。 4 月に発表した電子カルテシステム CLINICS カルテ ですが、何度かこちらのブログでもエントリが上がっていますとおり、電子カルテというシステムを構築する上で、セキュリティはかなり重要なウェイトを占める要素になっています。 このセキュリティを担保するための指針として 3 省 4 ガイドライン という総務省・経産省・厚労省の各省庁から出ている 4 種類のガイドラインが出ています。 これを実際に AWS をベースとしたシステムを構築する際の一例として CLINICS カルテでの構築例を発表しようということになりました。 発表スライド 当日の発表スライドはこちらになります。 電カルでガイドラインに沿うよう cloud trail とか vpc flow logs といった細かな AWS のサービス使ってるのか。 #rdm2018A #railsdm — yuyasat (@yuyasat) July 14, 2018 会場ではスライドの色見がすっごく色褪せしていたりしましたが、発表した中での AWS のサービスは会場のみなさんの中でも、あまり馴染みがないものが多いようでスライドの写真など撮られている方もいらっしゃって、知見共有という意味で参考になった模様です。 クライアント認証の話たのしいしめっちゃ知見だな。ALB, API Gateway は TLS クライアント認証に非対応だったので、Nginx で認証させてるとのこと。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 メドレーさんの発表、すげーよかった。 派手さはなくとも、こうやって一個ずつ地道に技術課題を解決している話はめちゃくちゃおもしろい。 #rdm2018A #railsdm — かつひささん (@katsuhisa__) July 14, 2018 やはりクライアント認証に関しては普段サービス開発ではそこまでは使われないので、興味を持っていただいたようで良かったです! まとめ 弊社のような医療業界ではなくても、フルマネージドサービスでセキュリティを意識するような場面があればご参考になるかもしれないテーマをエンジニアの宍戸から発表させていただきました。 社内で貯まった知見で機会があれば、ぜひ公開していきたいと思います。 メドレーについて気になった方は、こちらからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com