こんにちは、開発本部の高井です。 メドレーは、去年に引き続き 8/30〜9/2 に早稲田大学で開催された iOSDC Japan 2018 (以下 iOSDC)に協賛しました。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 （オンライン診療アプリ「CLINICS」初期開発時から Swift で実装しています） CLINICS(クリニクス)　オンライン診療・服薬指導アプリ メドレーは今回、シルバースポンサーとして協賛させていただきました。ブース出展はしていないのですが、スポンサー枠で私が参加してきました。 オープニングのスポンサー紹介は去年に引き続き今年も三石琴乃さんのナレーションでした！豪華です。 イベントの様子 ランチのお弁当はもちろん、朝はドーナツ、夕方の LT が始まるとビールが提供されるなど至れり尽くせりでした。セッションは最大 4 つが同時に進み、それに加えてアンカンファレンスと特定のテーマを設けたディスカッション企画などもあったのですが、進行も非常に円滑で非常に参加者の満足度の高いカンファレンスではないかと思います。 セッション 今年は Swift のコンパイラのソースから Swift の機能を解説するようなセッションがいくつかありました。去年はそのようなセッションはなかったのではないかと思います。Swift がオープンソース化されて 3 年弱ぐらいになり、日本でも Swift のコミュニティがより成熟しているように感じました。 また、機械学習などのキャッチーなトピックの話題が少し減って、業務上得た知見や設計についてなどの実用的なテーマが多かった印象でした。 特に View の設計や実装についてのセッションが面白かったです。やはり、iOS アプリ開発では View 周りの実装が悩みの多い領域ですよね。 ここからは特に気になったセッションをいくつかご紹介します。 MicroViewController で無限にスケールする iOS 開発 MicroViewController-en Shared by 齋藤暢郎 www.icloud.com UI パーツごとに ViewController を持たせて、一つの画面の異なる機能を複数のエンジニアで開発しやすいように実装しているというお話でした。一般的な画面単位で ViewController を持つ実装だと、開発の人数を増やしてもコンフリクトやオーバーヘッドが発生しやすくなり、効率的に開発することが難しくなってしまいます。そのため、開発チームの規模をスケールさせることができないということからそのような方法を取り入れたそうです。 MicroViewController を採用したことによって、一つのアプリに 20 人のエンジニアを充てることができるようになったということでしたが、他にそんなところあるのでしょうか、、、という気がしないでもなかったです。ただ、数人でやっていてもコンフリクトはよく起こりますし（project.pbxproj、、、！）、機能を追加したり、削除したりということを素早く試行錯誤するのには良さそうだなと思いました。 また、ビルドの効率化のためにサンドボックスアプリを用意したり、ViewController のテンプレートを作って実装の効率化を図るなど開発効率向上の参考になる取り組みも多かったです。 デバイス・ OS バージョンの依存が少なく、メンテナンスしやすいビューを作る ビューの実装について起こりがちな問題とその対処法について紹介したセッションでした。特にレイアウト崩れを防ぐために意識すべきポイントについて、具体的な失敗例を示しながら紹介されていました。 UI コンポーネントのサンプル実装（ https://github.com/folio-sec/Folio-UI-Collection/tree/master/Folio-UI-Collection ）も紹介されていましたが、CLINICS でも共通 UI をコンポーネント化して使っているので、カスタム View の実装方法やコンポーネントの粒度などが再確認でき、非常に有益でした。また、UI のユニットテストもあり、CLINICS ではあまり UI 関連のテストは書けていないので参考にしたいと思います。 宣言的 UICollectionView UICollectionView に複数の種類がある場合（よくあります！）に、宣言的な実装をすることでコードの見通しをよくする方法を提案されているセッションでした。 自分もあの switch 文をまとめようとして、うまくいかなかった経験があるのでとても興味深かったです。すぐに自分たちのコードにも適用できる実用的なセッションでした。 あとは ReactorKit のライブコーディングや差分検出アルゴリズムに関連する話がいくつかあり、ちょうど業務で ReactorKit と RxDataSources を使っているので参考になりました。 差分アルゴリズムの原理について UITableView などで変更があった箇所だけを更新するのに利用される差分検出のアルゴリズムについて解説したセッションでした。IGListKit や RxDataSources などで使われているアルゴリズムと Android の DiffUtil で利用されているアルゴリズムの原理について紹介されていました。ライブラリを使っていると、利用方法は分かるけど内部でどう動いてるかはあまり理解していないということも割とあると思いますが、その辺りを理解できると用途に応じて最適なライブラリを選択できたり、より効果的な使い方ができそうだと思いました。 5000 行の UITableView を差分更新する 差分更新のライブラリを使って多数行を更新した際に発生した問題の紹介とその原因を特定して、改善した内容についてのお話でした。採用していたライブラリは Differ でしたが、ライブラリごとの特徴や Instruments によるボトルネックの特定などが参考になりました。 まとめ iOSDC は去年に引き続きの参加だったのですが、今年のセッションもどれも興味深く、勉強になることが多かったです。またセッションの裏で特定の技術についてディスカッションするコーナーができるなど年々充実してきているように感じました。また、LT のときの会場の一体感はとても良いなあと思いました。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらからご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の高井です。 メドレーは、去年に引き続き 8/30〜9/2 に早稲田大学で開催された iOSDC Japan 2018 (以下 iOSDC)に協賛しました。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 （オンライン診療アプリ「CLINICS」初期開発時から Swift で実装しています） CLINICS(クリニクス)　オンライン診療・服薬指導アプリ メドレーは今回、シルバースポンサーとして協賛させていただきました。ブース出展はしていないのですが、スポンサー枠で私が参加してきました。 オープニングのスポンサー紹介は去年に引き続き今年も三石琴乃さんのナレーションでした！豪華です。 イベントの様子 ランチのお弁当はもちろん、朝はドーナツ、夕方の LT が始まるとビールが提供されるなど至れり尽くせりでした。セッションは最大 4 つが同時に進み、それに加えてアンカンファレンスと特定のテーマを設けたディスカッション企画などもあったのですが、進行も非常に円滑で非常に参加者の満足度の高いカンファレンスではないかと思います。 セッション 今年は Swift のコンパイラのソースから Swift の機能を解説するようなセッションがいくつかありました。去年はそのようなセッションはなかったのではないかと思います。Swift がオープンソース化されて 3 年弱ぐらいになり、日本でも Swift のコミュニティがより成熟しているように感じました。 また、機械学習などのキャッチーなトピックの話題が少し減って、業務上得た知見や設計についてなどの実用的なテーマが多かった印象でした。 特に View の設計や実装についてのセッションが面白かったです。やはり、iOS アプリ開発では View 周りの実装が悩みの多い領域ですよね。 ここからは特に気になったセッションをいくつかご紹介します。 MicroViewController で無限にスケールする iOS 開発 MicroViewController-en Shared by 齋藤暢郎 www.icloud.com UI パーツごとに ViewController を持たせて、一つの画面の異なる機能を複数のエンジニアで開発しやすいように実装しているというお話でした。一般的な画面単位で ViewController を持つ実装だと、開発の人数を増やしてもコンフリクトやオーバーヘッドが発生しやすくなり、効率的に開発することが難しくなってしまいます。そのため、開発チームの規模をスケールさせることができないということからそのような方法を取り入れたそうです。 MicroViewController を採用したことによって、一つのアプリに 20 人のエンジニアを充てることができるようになったということでしたが、他にそんなところあるのでしょうか、、、という気がしないでもなかったです。ただ、数人でやっていてもコンフリクトはよく起こりますし（project.pbxproj、、、！）、機能を追加したり、削除したりということを素早く試行錯誤するのには良さそうだなと思いました。 また、ビルドの効率化のためにサンドボックスアプリを用意したり、ViewController のテンプレートを作って実装の効率化を図るなど開発効率向上の参考になる取り組みも多かったです。 デバイス・ OS バージョンの依存が少なく、メンテナンスしやすいビューを作る ビューの実装について起こりがちな問題とその対処法について紹介したセッションでした。特にレイアウト崩れを防ぐために意識すべきポイントについて、具体的な失敗例を示しながら紹介されていました。 UI コンポーネントのサンプル実装（ https://github.com/folio-sec/Folio-UI-Collection/tree/master/Folio-UI-Collection ）も紹介されていましたが、CLINICS でも共通 UI をコンポーネント化して使っているので、カスタム View の実装方法やコンポーネントの粒度などが再確認でき、非常に有益でした。また、UI のユニットテストもあり、CLINICS ではあまり UI 関連のテストは書けていないので参考にしたいと思います。 宣言的 UICollectionView UICollectionView に複数の種類がある場合（よくあります！）に、宣言的な実装をすることでコードの見通しをよくする方法を提案されているセッションでした。 自分もあの switch 文をまとめようとして、うまくいかなかった経験があるのでとても興味深かったです。すぐに自分たちのコードにも適用できる実用的なセッションでした。 あとは ReactorKit のライブコーディングや差分検出アルゴリズムに関連する話がいくつかあり、ちょうど業務で ReactorKit と RxDataSources を使っているので参考になりました。 差分アルゴリズムの原理について UITableView などで変更があった箇所だけを更新するのに利用される差分検出のアルゴリズムについて解説したセッションでした。IGListKit や RxDataSources などで使われているアルゴリズムと Android の DiffUtil で利用されているアルゴリズムの原理について紹介されていました。ライブラリを使っていると、利用方法は分かるけど内部でどう動いてるかはあまり理解していないということも割とあると思いますが、その辺りを理解できると用途に応じて最適なライブラリを選択できたり、より効果的な使い方ができそうだと思いました。 5000 行の UITableView を差分更新する 差分更新のライブラリを使って多数行を更新した際に発生した問題の紹介とその原因を特定して、改善した内容についてのお話でした。採用していたライブラリは Differ でしたが、ライブラリごとの特徴や Instruments によるボトルネックの特定などが参考になりました。 まとめ iOSDC は去年に引き続きの参加だったのですが、今年のセッションもどれも興味深く、勉強になることが多かったです。またセッションの裏で特定の技術についてディスカッションするコーナーができるなど年々充実してきているように感じました。また、LT のときの会場の一体感はとても良いなあと思いました。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらからご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の高井です。 メドレーは、去年に引き続き 8/30〜9/2 に早稲田大学で開催された iOSDC Japan 2018 (以下 iOSDC)に協賛しました。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 （オンライン診療アプリ「CLINICS」初期開発時から Swift で実装しています） CLINICS(クリニクス)　オンライン診療・服薬指導アプリ メドレーは今回、シルバースポンサーとして協賛させていただきました。ブース出展はしていないのですが、スポンサー枠で私が参加してきました。 オープニングのスポンサー紹介は去年に引き続き今年も三石琴乃さんのナレーションでした！豪華です。 イベントの様子 ランチのお弁当はもちろん、朝はドーナツ、夕方の LT が始まるとビールが提供されるなど至れり尽くせりでした。セッションは最大 4 つが同時に進み、それに加えてアンカンファレンスと特定のテーマを設けたディスカッション企画などもあったのですが、進行も非常に円滑で非常に参加者の満足度の高いカンファレンスではないかと思います。 セッション 今年は Swift のコンパイラのソースから Swift の機能を解説するようなセッションがいくつかありました。去年はそのようなセッションはなかったのではないかと思います。Swift がオープンソース化されて 3 年弱ぐらいになり、日本でも Swift のコミュニティがより成熟しているように感じました。 また、機械学習などのキャッチーなトピックの話題が少し減って、業務上得た知見や設計についてなどの実用的なテーマが多かった印象でした。 特に View の設計や実装についてのセッションが面白かったです。やはり、iOS アプリ開発では View 周りの実装が悩みの多い領域ですよね。 ここからは特に気になったセッションをいくつかご紹介します。 MicroViewController で無限にスケールする iOS 開発 MicroViewController-en Shared by 齋藤暢郎 www.icloud.com UI パーツごとに ViewController を持たせて、一つの画面の異なる機能を複数のエンジニアで開発しやすいように実装しているというお話でした。一般的な画面単位で ViewController を持つ実装だと、開発の人数を増やしてもコンフリクトやオーバーヘッドが発生しやすくなり、効率的に開発することが難しくなってしまいます。そのため、開発チームの規模をスケールさせることができないということからそのような方法を取り入れたそうです。 MicroViewController を採用したことによって、一つのアプリに 20 人のエンジニアを充てることができるようになったということでしたが、他にそんなところあるのでしょうか、、、という気がしないでもなかったです。ただ、数人でやっていてもコンフリクトはよく起こりますし（project.pbxproj、、、！）、機能を追加したり、削除したりということを素早く試行錯誤するのには良さそうだなと思いました。 また、ビルドの効率化のためにサンドボックスアプリを用意したり、ViewController のテンプレートを作って実装の効率化を図るなど開発効率向上の参考になる取り組みも多かったです。 デバイス・ OS バージョンの依存が少なく、メンテナンスしやすいビューを作る ビューの実装について起こりがちな問題とその対処法について紹介したセッションでした。特にレイアウト崩れを防ぐために意識すべきポイントについて、具体的な失敗例を示しながら紹介されていました。 UI コンポーネントのサンプル実装（ https://github.com/folio-sec/Folio-UI-Collection/tree/master/Folio-UI-Collection ）も紹介されていましたが、CLINICS でも共通 UI をコンポーネント化して使っているので、カスタム View の実装方法やコンポーネントの粒度などが再確認でき、非常に有益でした。また、UI のユニットテストもあり、CLINICS ではあまり UI 関連のテストは書けていないので参考にしたいと思います。 宣言的 UICollectionView UICollectionView に複数の種類がある場合（よくあります！）に、宣言的な実装をすることでコードの見通しをよくする方法を提案されているセッションでした。 自分もあの switch 文をまとめようとして、うまくいかなかった経験があるのでとても興味深かったです。すぐに自分たちのコードにも適用できる実用的なセッションでした。 あとは ReactorKit のライブコーディングや差分検出アルゴリズムに関連する話がいくつかあり、ちょうど業務で ReactorKit と RxDataSources を使っているので参考になりました。 差分アルゴリズムの原理について UITableView などで変更があった箇所だけを更新するのに利用される差分検出のアルゴリズムについて解説したセッションでした。IGListKit や RxDataSources などで使われているアルゴリズムと Android の DiffUtil で利用されているアルゴリズムの原理について紹介されていました。ライブラリを使っていると、利用方法は分かるけど内部でどう動いてるかはあまり理解していないということも割とあると思いますが、その辺りを理解できると用途に応じて最適なライブラリを選択できたり、より効果的な使い方ができそうだと思いました。 5000 行の UITableView を差分更新する 差分更新のライブラリを使って多数行を更新した際に発生した問題の紹介とその原因を特定して、改善した内容についてのお話でした。採用していたライブラリは Differ でしたが、ライブラリごとの特徴や Instruments によるボトルネックの特定などが参考になりました。 まとめ iOSDC は去年に引き続きの参加だったのですが、今年のセッションもどれも興味深く、勉強になることが多かったです。またセッションの裏で特定の技術についてディスカッションするコーナーができるなど年々充実してきているように感じました。また、LT のときの会場の一体感はとても良いなあと思いました。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらからご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の高井です。 メドレーは、去年に引き続き 8/30〜9/2 に早稲田大学で開催された iOSDC Japan 2018 (以下 iOSDC)に協賛しました。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 （オンライン診療アプリ「CLINICS」初期開発時から Swift で実装しています） CLINICS(クリニクス)　オンライン診療・服薬指導アプリ メドレーは今回、シルバースポンサーとして協賛させていただきました。ブース出展はしていないのですが、スポンサー枠で私が参加してきました。 オープニングのスポンサー紹介は去年に引き続き今年も三石琴乃さんのナレーションでした！豪華です。 イベントの様子 ランチのお弁当はもちろん、朝はドーナツ、夕方の LT が始まるとビールが提供されるなど至れり尽くせりでした。セッションは最大 4 つが同時に進み、それに加えてアンカンファレンスと特定のテーマを設けたディスカッション企画などもあったのですが、進行も非常に円滑で非常に参加者の満足度の高いカンファレンスではないかと思います。 セッション 今年は Swift のコンパイラのソースから Swift の機能を解説するようなセッションがいくつかありました。去年はそのようなセッションはなかったのではないかと思います。Swift がオープンソース化されて 3 年弱ぐらいになり、日本でも Swift のコミュニティがより成熟しているように感じました。 また、機械学習などのキャッチーなトピックの話題が少し減って、業務上得た知見や設計についてなどの実用的なテーマが多かった印象でした。 特に View の設計や実装についてのセッションが面白かったです。やはり、iOS アプリ開発では View 周りの実装が悩みの多い領域ですよね。 ここからは特に気になったセッションをいくつかご紹介します。 MicroViewController で無限にスケールする iOS 開発 MicroViewController-en Shared by 齋藤暢郎 www.icloud.com UI パーツごとに ViewController を持たせて、一つの画面の異なる機能を複数のエンジニアで開発しやすいように実装しているというお話でした。一般的な画面単位で ViewController を持つ実装だと、開発の人数を増やしてもコンフリクトやオーバーヘッドが発生しやすくなり、効率的に開発することが難しくなってしまいます。そのため、開発チームの規模をスケールさせることができないということからそのような方法を取り入れたそうです。 MicroViewController を採用したことによって、一つのアプリに 20 人のエンジニアを充てることができるようになったということでしたが、他にそんなところあるのでしょうか、、、という気がしないでもなかったです。ただ、数人でやっていてもコンフリクトはよく起こりますし（project.pbxproj、、、！）、機能を追加したり、削除したりということを素早く試行錯誤するのには良さそうだなと思いました。 また、ビルドの効率化のためにサンドボックスアプリを用意したり、ViewController のテンプレートを作って実装の効率化を図るなど開発効率向上の参考になる取り組みも多かったです。 デバイス・ OS バージョンの依存が少なく、メンテナンスしやすいビューを作る ビューの実装について起こりがちな問題とその対処法について紹介したセッションでした。特にレイアウト崩れを防ぐために意識すべきポイントについて、具体的な失敗例を示しながら紹介されていました。 UI コンポーネントのサンプル実装（ https://github.com/folio-sec/Folio-UI-Collection/tree/master/Folio-UI-Collection ）も紹介されていましたが、CLINICS でも共通 UI をコンポーネント化して使っているので、カスタム View の実装方法やコンポーネントの粒度などが再確認でき、非常に有益でした。また、UI のユニットテストもあり、CLINICS ではあまり UI 関連のテストは書けていないので参考にしたいと思います。 宣言的 UICollectionView UICollectionView に複数の種類がある場合（よくあります！）に、宣言的な実装をすることでコードの見通しをよくする方法を提案されているセッションでした。 自分もあの switch 文をまとめようとして、うまくいかなかった経験があるのでとても興味深かったです。すぐに自分たちのコードにも適用できる実用的なセッションでした。 あとは ReactorKit のライブコーディングや差分検出アルゴリズムに関連する話がいくつかあり、ちょうど業務で ReactorKit と RxDataSources を使っているので参考になりました。 差分アルゴリズムの原理について UITableView などで変更があった箇所だけを更新するのに利用される差分検出のアルゴリズムについて解説したセッションでした。IGListKit や RxDataSources などで使われているアルゴリズムと Android の DiffUtil で利用されているアルゴリズムの原理について紹介されていました。ライブラリを使っていると、利用方法は分かるけど内部でどう動いてるかはあまり理解していないということも割とあると思いますが、その辺りを理解できると用途に応じて最適なライブラリを選択できたり、より効果的な使い方ができそうだと思いました。 5000 行の UITableView を差分更新する 差分更新のライブラリを使って多数行を更新した際に発生した問題の紹介とその原因を特定して、改善した内容についてのお話でした。採用していたライブラリは Differ でしたが、ライブラリごとの特徴や Instruments によるボトルネックの特定などが参考になりました。 まとめ iOSDC は去年に引き続きの参加だったのですが、今年のセッションもどれも興味深く、勉強になることが多かったです。またセッションの裏で特定の技術についてディスカッションするコーナーができるなど年々充実してきているように感じました。また、LT のときの会場の一体感はとても良いなあと思いました。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらからご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部の高井です。 メドレーは、去年に引き続き 8/30〜9/2 に早稲田大学で開催された iOSDC Japan 2018 (以下 iOSDC)に協賛しました。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 （オンライン診療アプリ「CLINICS」初期開発時から Swift で実装しています） CLINICS(クリニクス)　オンライン診療・服薬指導アプリ メドレーは今回、シルバースポンサーとして協賛させていただきました。ブース出展はしていないのですが、スポンサー枠で私が参加してきました。 オープニングのスポンサー紹介は去年に引き続き今年も三石琴乃さんのナレーションでした！豪華です。 イベントの様子 ランチのお弁当はもちろん、朝はドーナツ、夕方の LT が始まるとビールが提供されるなど至れり尽くせりでした。セッションは最大 4 つが同時に進み、それに加えてアンカンファレンスと特定のテーマを設けたディスカッション企画などもあったのですが、進行も非常に円滑で非常に参加者の満足度の高いカンファレンスではないかと思います。 セッション 今年は Swift のコンパイラのソースから Swift の機能を解説するようなセッションがいくつかありました。去年はそのようなセッションはなかったのではないかと思います。Swift がオープンソース化されて 3 年弱ぐらいになり、日本でも Swift のコミュニティがより成熟しているように感じました。 また、機械学習などのキャッチーなトピックの話題が少し減って、業務上得た知見や設計についてなどの実用的なテーマが多かった印象でした。 特に View の設計や実装についてのセッションが面白かったです。やはり、iOS アプリ開発では View 周りの実装が悩みの多い領域ですよね。 ここからは特に気になったセッションをいくつかご紹介します。 MicroViewController で無限にスケールする iOS 開発 MicroViewController-en Shared by 齋藤暢郎 www.icloud.com UI パーツごとに ViewController を持たせて、一つの画面の異なる機能を複数のエンジニアで開発しやすいように実装しているというお話でした。一般的な画面単位で ViewController を持つ実装だと、開発の人数を増やしてもコンフリクトやオーバーヘッドが発生しやすくなり、効率的に開発することが難しくなってしまいます。そのため、開発チームの規模をスケールさせることができないということからそのような方法を取り入れたそうです。 MicroViewController を採用したことによって、一つのアプリに 20 人のエンジニアを充てることができるようになったということでしたが、他にそんなところあるのでしょうか、、、という気がしないでもなかったです。ただ、数人でやっていてもコンフリクトはよく起こりますし（project.pbxproj、、、！）、機能を追加したり、削除したりということを素早く試行錯誤するのには良さそうだなと思いました。 また、ビルドの効率化のためにサンドボックスアプリを用意したり、ViewController のテンプレートを作って実装の効率化を図るなど開発効率向上の参考になる取り組みも多かったです。 デバイス・ OS バージョンの依存が少なく、メンテナンスしやすいビューを作る ビューの実装について起こりがちな問題とその対処法について紹介したセッションでした。特にレイアウト崩れを防ぐために意識すべきポイントについて、具体的な失敗例を示しながら紹介されていました。 UI コンポーネントのサンプル実装（ https://github.com/folio-sec/Folio-UI-Collection/tree/master/Folio-UI-Collection ）も紹介されていましたが、CLINICS でも共通 UI をコンポーネント化して使っているので、カスタム View の実装方法やコンポーネントの粒度などが再確認でき、非常に有益でした。また、UI のユニットテストもあり、CLINICS ではあまり UI 関連のテストは書けていないので参考にしたいと思います。 宣言的 UICollectionView UICollectionView に複数の種類がある場合（よくあります！）に、宣言的な実装をすることでコードの見通しをよくする方法を提案されているセッションでした。 自分もあの switch 文をまとめようとして、うまくいかなかった経験があるのでとても興味深かったです。すぐに自分たちのコードにも適用できる実用的なセッションでした。 あとは ReactorKit のライブコーディングや差分検出アルゴリズムに関連する話がいくつかあり、ちょうど業務で ReactorKit と RxDataSources を使っているので参考になりました。 差分アルゴリズムの原理について UITableView などで変更があった箇所だけを更新するのに利用される差分検出のアルゴリズムについて解説したセッションでした。IGListKit や RxDataSources などで使われているアルゴリズムと Android の DiffUtil で利用されているアルゴリズムの原理について紹介されていました。ライブラリを使っていると、利用方法は分かるけど内部でどう動いてるかはあまり理解していないということも割とあると思いますが、その辺りを理解できると用途に応じて最適なライブラリを選択できたり、より効果的な使い方ができそうだと思いました。 5000 行の UITableView を差分更新する 差分更新のライブラリを使って多数行を更新した際に発生した問題の紹介とその原因を特定して、改善した内容についてのお話でした。採用していたライブラリは Differ でしたが、ライブラリごとの特徴や Instruments によるボトルネックの特定などが参考になりました。 まとめ iOSDC は去年に引き続きの参加だったのですが、今年のセッションもどれも興味深く、勉強になることが多かったです。またセッションの裏で特定の技術についてディスカッションするコーナーができるなど年々充実してきているように感じました。また、LT のときの会場の一体感はとても良いなあと思いました。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらからご連絡ください。 株式会社メドレーの会社情報 - Wantedly 株式会社メドレーの魅力を伝えるコンテンツと、住所や代表・従業員などの会社情報です。急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは、開発本部平木です。去る 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 版で使っています。 https://play.google.com/store/apps/details?id=life.medley.clinics 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 版で使っています。 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 カンファレンスをスポンサードして参ります。色々な場所で、お会いできたらと思います！

こんにちは、開発本部平木です。去る 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 版で使っています。 melmo（メルモ） - Apps on Google Play Making hospital visits easier and medical care more accessible. Melmo allows you to make appointments, send prescriptions in advance, have medication delivered, and even manage your medication record, all with just 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 で実現できましたが、運用していく上での課題については、引き続き検討して行きたいと思います。