こんにちは！開発本部のエンジニア・後藤です。 メドレーは 5/31〜6/2 に開催された RurbyKaigi 2018 に Lightning Talks Sponsor として協賛させていただきました（ 昨年 の Ruby Sponsor に続き、2 年目の協賛です）。 イベント当日は、弊社から CTO の平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の 6 人が参加しました。今回はその様子などをレポートします。 会場の様子 RubyKaigi 2018 は 仙台国際センター での開催でした。昨年は 広島 、一昨年は 京都 ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。 仙台国際センターは仙台駅から地下鉄東西線で 3 駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。 メイン会場は 1000 人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。 世界地図&日本地図。様々な地域からの参加者がいますね！（rubyists に map メソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。） 地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。 ブースの様子 続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。 All photographs will be uploaded to this URLs(google photo). day1 https://t.co/w6Dgq8HBb4 day2 https://t.co/X1x03bFEDF day3 https://t.co/8rlXpfZTEB See you next year! #RubyKaigi #RubyKaigi2018 — nil (@KatsumaNarisawa) June 2, 2018 ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。 ブースにはおかげさまで、たくさんの方にお越しいただきました！ CTO 平山の発表 そして、初日の Lightning Talks 前のスポンサーの PR 枠にて弊社の CTO 平山が発表をしました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、また、以前 本ブログで紹介 しました 3 本のニュースリリースを含めたこの 1 年のアップデート内容を中心に紹介させていただきました。 公演の途中での CTO 平山からメドレーのことを知っている人？との問いかけで、7・ 8 割の方が挙手をしていたのは感慨深かったです。 当日のスライドはこちらです。 現地での反応 ブース展示、PR 枠での発表を通じて以下のような嬉しい反応もいただきました！ オンライン診療はもっと普及すべきですね、地方医療の課題解決にも繋がる素晴らしい取り組みだと思う。 #rubikaigi2018 #rubykaigi #メドレー — ふじこ / SHOWROOM の人事おねえさん (@yufujikochan) May 31, 2018 [https://twitter.com/yucao24hours/status/1002105819297595392:embed] 指先を切ってしまったけど絆創膏をノベルティで配ってるから安心 #rubykaigi pic.twitter.com/NeXWfTif6m — Motonori Iwata (@mobcov) June 1, 2018 ブースでも、2 日目以降「1 日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについて Rubyist の皆様に知っていただくとても良い機会になっていたと思いました。 セッションの様子 エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですが mruby や型、パフォーマンス周りの話題が多かったように思います。まさに 2018 年現在の Ruby を取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。 初日の keynote での 1 コマ。 Matz さんの keynote にもありましたが何事も「塞翁が馬」です。毎年 Ruby は死に、そして生まれ変わります（クリスマスに）。Ruby も常に進化していることを肌で感じることのできるセッション群でした。 番外編 さて、メドレー恒例（？）のお参りですが今回は大崎八幡宮に参詣することになりました。 大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。 参拝する 3 人。 参拝する 2 人とそれを撮影する 2 人。 さいごに 昨年に引き続きメドレーの RubyKaigi 協賛は 2 度目になりました。 ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上に Ruby、医療 ×IT を盛り上げていければという気持ちを胸に仙台を後にしました。 （新幹線から仙台の夕焼けをパシャリ） お知らせ 弊社では「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 https://www.medley.jp/recruit/creative.html

こんにちは！開発本部のエンジニア・後藤です。 メドレーは 5/31〜6/2 に開催された RurbyKaigi 2018 に Lightning Talks Sponsor として協賛させていただきました（ 昨年 の Ruby Sponsor に続き、2 年目の協賛です）。 イベント当日は、弊社から CTO の平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の 6 人が参加しました。今回はその様子などをレポートします。 会場の様子 RubyKaigi 2018 は 仙台国際センター での開催でした。昨年は 広島 、一昨年は 京都 ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。 仙台国際センターは仙台駅から地下鉄東西線で 3 駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。 メイン会場は 1000 人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。 世界地図&日本地図。様々な地域からの参加者がいますね！（rubyists に map メソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。） 地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。 ブースの様子 続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。 All photographs will be uploaded to this URLs(google photo). day1 https://t.co/w6Dgq8HBb4 day2 https://t.co/X1x03bFEDF day3 https://t.co/8rlXpfZTEB See you next year! #RubyKaigi #RubyKaigi2018 — nil (@KatsumaNarisawa) June 2, 2018 ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。 ブースにはおかげさまで、たくさんの方にお越しいただきました！ CTO 平山の発表 そして、初日の Lightning Talks 前のスポンサーの PR 枠にて弊社の CTO 平山が発表をしました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、また、以前 本ブログで紹介 しました 3 本のニュースリリースを含めたこの 1 年のアップデート内容を中心に紹介させていただきました。 公演の途中での CTO 平山からメドレーのことを知っている人？との問いかけで、7・ 8 割の方が挙手をしていたのは感慨深かったです。 当日のスライドはこちらです。 現地での反応 ブース展示、PR 枠での発表を通じて以下のような嬉しい反応もいただきました！ オンライン診療はもっと普及すべきですね、地方医療の課題解決にも繋がる素晴らしい取り組みだと思う。 #rubikaigi2018 #rubykaigi #メドレー — ふじこ / SHOWROOM の人事おねえさん (@yufujikochan) May 31, 2018 [https://twitter.com/yucao24hours/status/1002105819297595392:embed] 指先を切ってしまったけど絆創膏をノベルティで配ってるから安心 #rubykaigi pic.twitter.com/NeXWfTif6m — Motonori Iwata (@mobcov) June 1, 2018 ブースでも、2 日目以降「1 日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについて Rubyist の皆様に知っていただくとても良い機会になっていたと思いました。 セッションの様子 エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですが mruby や型、パフォーマンス周りの話題が多かったように思います。まさに 2018 年現在の Ruby を取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。 初日の keynote での 1 コマ。 Matz さんの keynote にもありましたが何事も「塞翁が馬」です。毎年 Ruby は死に、そして生まれ変わります（クリスマスに）。Ruby も常に進化していることを肌で感じることのできるセッション群でした。 番外編 さて、メドレー恒例（？）のお参りですが今回は大崎八幡宮に参詣することになりました。 大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。 参拝する 3 人。 参拝する 2 人とそれを撮影する 2 人。 さいごに 昨年に引き続きメドレーの RubyKaigi 協賛は 2 度目になりました。 ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上に Ruby、医療 ×IT を盛り上げていければという気持ちを胸に仙台を後にしました。 （新幹線から仙台の夕焼けをパシャリ） お知らせ 弊社では「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 https://www.medley.jp/recruit/creative.html

こんにちは！開発本部のエンジニア・後藤です。 メドレーは 5/31〜6/2 に開催された RurbyKaigi 2018 に Lightning Talks Sponsor として協賛させていただきました（ 昨年 の Ruby Sponsor に続き、2 年目の協賛です）。 イベント当日は、弊社から CTO の平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の 6 人が参加しました。今回はその様子などをレポートします。 会場の様子 RubyKaigi 2018 は 仙台国際センター での開催でした。昨年は 広島 、一昨年は 京都 ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。 仙台国際センターは仙台駅から地下鉄東西線で 3 駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。 メイン会場は 1000 人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。 世界地図&日本地図。様々な地域からの参加者がいますね！（rubyists に map メソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。） 地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。 ブースの様子 続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。 All photographs will be uploaded to this URLs(google photo). day1 https://t.co/w6Dgq8HBb4 day2 https://t.co/X1x03bFEDF day3 https://t.co/8rlXpfZTEB See you next year! #RubyKaigi #RubyKaigi2018 — nil (@KatsumaNarisawa) June 2, 2018 ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。 ブースにはおかげさまで、たくさんの方にお越しいただきました！ CTO 平山の発表 そして、初日の Lightning Talks 前のスポンサーの PR 枠にて弊社の CTO 平山が発表をしました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、また、以前 本ブログで紹介 しました 3 本のニュースリリースを含めたこの 1 年のアップデート内容を中心に紹介させていただきました。 公演の途中での CTO 平山からメドレーのことを知っている人？との問いかけで、7・ 8 割の方が挙手をしていたのは感慨深かったです。 当日のスライドはこちらです。 現地での反応 ブース展示、PR 枠での発表を通じて以下のような嬉しい反応もいただきました！ オンライン診療はもっと普及すべきですね、地方医療の課題解決にも繋がる素晴らしい取り組みだと思う。 #rubikaigi2018 #rubykaigi #メドレー — ふじこ / SHOWROOM の人事おねえさん (@yufujikochan) May 31, 2018 [https://twitter.com/yucao24hours/status/1002105819297595392:embed] 指先を切ってしまったけど絆創膏をノベルティで配ってるから安心 #rubykaigi pic.twitter.com/NeXWfTif6m — Motonori Iwata (@mobcov) June 1, 2018 ブースでも、2 日目以降「1 日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについて Rubyist の皆様に知っていただくとても良い機会になっていたと思いました。 セッションの様子 エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですが mruby や型、パフォーマンス周りの話題が多かったように思います。まさに 2018 年現在の Ruby を取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。 初日の keynote での 1 コマ。 Matz さんの keynote にもありましたが何事も「塞翁が馬」です。毎年 Ruby は死に、そして生まれ変わります（クリスマスに）。Ruby も常に進化していることを肌で感じることのできるセッション群でした。 番外編 さて、メドレー恒例（？）のお参りですが今回は大崎八幡宮に参詣することになりました。 大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。 参拝する 3 人。 参拝する 2 人とそれを撮影する 2 人。 さいごに 昨年に引き続きメドレーの RubyKaigi 協賛は 2 度目になりました。 ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上に Ruby、医療 ×IT を盛り上げていければという気持ちを胸に仙台を後にしました。 （新幹線から仙台の夕焼けをパシャリ） お知らせ 弊社では「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 https://www.medley.jp/recruit/creative.html

こんにちは！開発本部のエンジニア・後藤です。 メドレーは 5/31〜6/2 に開催された RurbyKaigi 2018 に Lightning Talks Sponsor として協賛させていただきました（ 昨年 の Ruby Sponsor に続き、2 年目の協賛です）。 イベント当日は、弊社から CTO の平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の 6 人が参加しました。今回はその様子などをレポートします。 会場の様子 RubyKaigi 2018 は 仙台国際センター での開催でした。昨年は 広島 、一昨年は 京都 ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。 仙台国際センターは仙台駅から地下鉄東西線で 3 駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。 メイン会場は 1000 人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。 世界地図&日本地図。様々な地域からの参加者がいますね！（rubyists に map メソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。） 地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。 ブースの様子 続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。 All photographs will be uploaded to this URLs(google photo). day1 https://t.co/w6Dgq8HBb4 day2 https://t.co/X1x03bFEDF day3 https://t.co/8rlXpfZTEB See you next year! #RubyKaigi #RubyKaigi2018 — nil (@KatsumaNarisawa) June 2, 2018 ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。 ブースにはおかげさまで、たくさんの方にお越しいただきました！ CTO 平山の発表 そして、初日の Lightning Talks 前のスポンサーの PR 枠にて弊社の CTO 平山が発表をしました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、また、以前 本ブログで紹介 しました 3 本のニュースリリースを含めたこの 1 年のアップデート内容を中心に紹介させていただきました。 公演の途中での CTO 平山からメドレーのことを知っている人？との問いかけで、7・ 8 割の方が挙手をしていたのは感慨深かったです。 当日のスライドはこちらです。 現地での反応 ブース展示、PR 枠での発表を通じて以下のような嬉しい反応もいただきました！ オンライン診療はもっと普及すべきですね、地方医療の課題解決にも繋がる素晴らしい取り組みだと思う。 #rubikaigi2018 #rubykaigi #メドレー — ふじこ / SHOWROOM の人事おねえさん (@yufujikochan) May 31, 2018 [https://twitter.com/yucao24hours/status/1002105819297595392:embed] 指先を切ってしまったけど絆創膏をノベルティで配ってるから安心 #rubykaigi pic.twitter.com/NeXWfTif6m — Motonori Iwata (@mobcov) June 1, 2018 ブースでも、2 日目以降「1 日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについて Rubyist の皆様に知っていただくとても良い機会になっていたと思いました。 セッションの様子 エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですが mruby や型、パフォーマンス周りの話題が多かったように思います。まさに 2018 年現在の Ruby を取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。 初日の keynote での 1 コマ。 Matz さんの keynote にもありましたが何事も「塞翁が馬」です。毎年 Ruby は死に、そして生まれ変わります（クリスマスに）。Ruby も常に進化していることを肌で感じることのできるセッション群でした。 番外編 さて、メドレー恒例（？）のお参りですが今回は大崎八幡宮に参詣することになりました。 大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。 参拝する 3 人。 参拝する 2 人とそれを撮影する 2 人。 さいごに 昨年に引き続きメドレーの RubyKaigi 協賛は 2 度目になりました。 ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上に Ruby、医療 ×IT を盛り上げていければという気持ちを胸に仙台を後にしました。 （新幹線から仙台の夕焼けをパシャリ） お知らせ 弊社では「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 https://www.medley.jp/recruit/creative.html

こんにちは！開発本部のエンジニア・後藤です。 メドレーは 5/31〜6/2 に開催された RurbyKaigi 2018 に Lightning Talks Sponsor として協賛させていただきました（ 昨年 の Ruby Sponsor に続き、2 年目の協賛です）。 イベント当日は、弊社から CTO の平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の 6 人が参加しました。今回はその様子などをレポートします。 会場の様子 RubyKaigi 2018 は 仙台国際センター での開催でした。昨年は 広島 、一昨年は 京都 ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。 仙台国際センターは仙台駅から地下鉄東西線で 3 駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。 メイン会場は 1000 人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。 世界地図&日本地図。様々な地域からの参加者がいますね！（rubyists に map メソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。） 地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。 ブースの様子 続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。 All photographs will be uploaded to this URLs(google photo). day1 https://t.co/w6Dgq8HBb4 day2 https://t.co/X1x03bFEDF day3 https://t.co/8rlXpfZTEB See you next year! #RubyKaigi #RubyKaigi2018 — nil (@KatsumaNarisawa) June 2, 2018 ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。 ブースにはおかげさまで、たくさんの方にお越しいただきました！ CTO 平山の発表 そして、初日の Lightning Talks 前のスポンサーの PR 枠にて弊社の CTO 平山が発表をしました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、また、以前 本ブログで紹介 しました 3 本のニュースリリースを含めたこの 1 年のアップデート内容を中心に紹介させていただきました。 公演の途中での CTO 平山からメドレーのことを知っている人？との問いかけで、7・ 8 割の方が挙手をしていたのは感慨深かったです。 当日のスライドはこちらです。 現地での反応 ブース展示、PR 枠での発表を通じて以下のような嬉しい反応もいただきました！ オンライン診療はもっと普及すべきですね、地方医療の課題解決にも繋がる素晴らしい取り組みだと思う。 #rubikaigi2018 #rubykaigi #メドレー — ふじこ / SHOWROOM の人事おねえさん (@yufujikochan) May 31, 2018 [https://twitter.com/yucao24hours/status/1002105819297595392:embed] 指先を切ってしまったけど絆創膏をノベルティで配ってるから安心 #rubykaigi pic.twitter.com/NeXWfTif6m — Motonori Iwata (@mobcov) June 1, 2018 ブースでも、2 日目以降「1 日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについて Rubyist の皆様に知っていただくとても良い機会になっていたと思いました。 セッションの様子 エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですが mruby や型、パフォーマンス周りの話題が多かったように思います。まさに 2018 年現在の Ruby を取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。 初日の keynote での 1 コマ。 Matz さんの keynote にもありましたが何事も「塞翁が馬」です。毎年 Ruby は死に、そして生まれ変わります（クリスマスに）。Ruby も常に進化していることを肌で感じることのできるセッション群でした。 番外編 さて、メドレー恒例（？）のお参りですが今回は大崎八幡宮に参詣することになりました。 大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。 参拝する 3 人。 参拝する 2 人とそれを撮影する 2 人。 さいごに 昨年に引き続きメドレーの RubyKaigi 協賛は 2 度目になりました。 ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上に Ruby、医療 ×IT を盛り上げていければという気持ちを胸に仙台を後にしました。 （新幹線から仙台の夕焼けをパシャリ） お知らせ 弊社では「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 株式会社メドレーの会社情報 - Wantedly 株式会社メドレーの魅力を伝えるコンテンツと、住所や代表・従業員などの会社情報です。急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 https://www.medley.jp/recruit/creative.html

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ https://rubykaigi.org/2018

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」で React Native について発表しました。 私は普段は Swift、Kotlin/Java を使ってネイティブアプリを開発しており、React Native に触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。 なぜ React Native を触ってみようと思ったか オンライン診療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。 これらの課題に対して こちら のブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。 その中でも以下の理由から、今回は React Native について調べてみることにしました。 JavaScript（以下 JS）・ React のため、Web エンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう UI の実装にネイティブ UI を使用しているので自然なデザインやインタラクションを作りやすそう ある程度リリースから時間が経って情報が豊富にある 特に弊社では、ネイティブアプリより Web 開発をメインに行ってきたエンジニアの方が多く、また Web フロントに React が使われているプロダクトもいくつかあるので、React Native を採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。 そこで、以降ではネイティブアプリエンジニアと Web エンジニアそれぞれにとって、開発しやすいかどうかという観点で React Native の開発方法を見ていきたいと思います。 初期設定について インストール〜アプリ実行 インストールは公式の Getting Started にもありますが、以下のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が触るにあたっては Xcode と Android Studio のシミュレータ（エミュレータ）で実行しながら開発しましたが、React Native は Xcode や Android Studio がインストールされていなくても、 Expo というクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。 これなら、Xcode のダウンロードを待つ必要もありません！（iOS エンジニアでもアップグレードのたびに Xcode のダウンロードを待つのはイライラします） 次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。 ただし、シミュレータ実行前に Xcode Command Line Tools のインストールと Android Studio でいくつかの設定（SDK のインストール、AVD の作成、環境変数の設定）が必要です。 # プロジェクト作成 $ react-native init AwesomeProject  # アプリ実行（シミュレータ） $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の場合、emulator を別途起動してからでないと実行できない 実装してみた感想 UI の実装方法 React Native では React 同様 UI の各パーツをコンポーネントと呼び、それらを配置することで UI を実装していきます。違いは Web の HTML の代わりに Native の UI を描画するためのコンポーネントとして使う点です。 見た目やレイアウトは CSS と似たような形式で記述します。React Native で使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、View コンポーネントに設定できるプロパティには以下のようなものがあります。 View Style Props Layout Props Web で使われているものと全く同じというわけではないですが、flex、margin、border などの使い慣れている CSS のプロパティ名で設定できるので、Web エンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段 CSS を触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。 また一度ビルドすれば、JS による修正内容をビルドなしでシミュレータに反映することができるので、View 周りの調整は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。 例えば、TabBar(iOS)と DrawerLayout(Android)、DatePicker(iOS)と TimePicker(Android)、ProgressView(iOS)と ProgressBar(Android)などは React Native では別コンポーネントとして提供されていて、API も違っていました。 画面遷移 画面遷移（プッシュ、モーダル、タブ遷移など）のために API として公式で提供されているのは iOS のみで Android は別途、実装するか、サードパーティのライブラリを使用する必要があります。 わたしが使ってみた react-native-navigation はモーダル、プッシュなどの遷移がネイティブ API ベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。 下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。 それでも、iOS と Android では複数画面の管理や遷移についての考え方が違い、Android を初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特に Web だとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モーダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワーク周り ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うには Fetch API を利用します。 Fetch API は JS で提供されている Promise ベースの API です。例えば、以下のような形で JSON を返す API からデータを取得し、 receiveHelthNews 関数にオブジェクトに変換した配列を渡すことができます。JS の API なので Web エンジニアにとっては使いやすいのではないかと思います。 ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)と HttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、API は異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネイティブアプリ特有の機能について その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。 Push 通知：Android はハンドリングする API が公式で提供されていないのでサードパーティのライブラリを使う カメラ、キーチェーンアクセス/ユーザデフォルト：公式の API は提供されていないのでサードパーティのライブラリを使う 位置情報の取得：公式 API が提供されている ディープリンク：アプリ起動時にハンドリングを行う API は提供されている。ユニバーサルリンクや IntentFilter の設定は各プラットフォームで個別に必要になる リリースはどうやるか アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。 各プラットフォームで証明書等の設定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行して、ipa / apk ファイルを作成し、各 Store にアップロードする必要があります。 CI は Bitrise などが使えます。Bitrise でビルドを試してみましたが、React Native のリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に 2 プラットフォームのアーカイブが作成できて便利でした。 あと、まだ試せてはいないのですが CodePush を使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。 どんな場合に React Native を採用できそうか? React Native で開発することで、Web 開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。 一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。React と JS、また Redux なども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View 周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。 運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Push など便利なツールもあるので利点が多いと思いました。 結論としては、Web エンジニアが社内に多かったり、開発チームに React、JS が得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。 まとめ 自分の現状で考えると、アプリは得意だけど JS や React にそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。 わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。 お知らせ メドレーは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください！ RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 https://github.com/antirez/redis/blob/3.2.10/src/server.c#L3343-L3357 ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 https://www.medley.jp/recruit/creative.html メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 https://rubykaigi.org/2018

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 ジョブメドレーでは各種キャッシュや sidekiq の queue 等に ElastiCache for Redis を利用しています。 先日、メドレーで定期開催している社内勉強会 TechLunch にて、ジョブメドレーでの ElastiCache for Redis の運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。 キー削除周りの仕様について キャッシュとして ElastiCache for Redis を利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。 Redis 本家の Expiration/Eviction Expiration については Redis ではキーに TTL を設定することで有効期限を設定することができ、 こちら に記載のロジックで削除処理を実施してくれます。 Eviction については Redis 本家の実装では以下のような仕様になっています。Redis 本家ドキュメントは こちら 。 used_memory （アプリが利用しているメモリ量）が maxmemory 値を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで設定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必要なオペレーションでは evit せず、エラーとなる allkeys-lru : 常に LRU アルゴリズムで削除対象選定 volatile-lru : TTL が設定されたキー内で LRU アルゴリズムで削除対象選定 allkeys-random : 常にランダムに削除対象選定して削除 volatile-random : TTL が設定されたキー内でランダムに削除対象選定 volatile-ttl : TTL が設定されたキー内で TTL また、ElastiCache for Redis ではまだ 3 系列までしか使えませんが、4 系列では新たに LFU も選択肢に入ってくるようです。 Redis 本家の Eviction の動作仕様としては以下のイメージです。 github.com github.com ElastiCache for Redis では maxmemory は編集できず、その代わりに後述する reserved-memory （ reserved-memory-percent ）を設定すると Eviction が発火するメモリ量の閾値が変わることから上記周りの実装は AWS 側で手を入れていそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以下のように Redis 本家にはない reserved-memory という概念があるので注意が必要です。 maxmemory はインスタンスタイプによって固定値に設定されている maxmemory は 変更できない 代わりに reserved-memory or reserved-memory-percent を設定して Eviction 発火メモリ量を設定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 古めのインスタンス（2017 年 3 月 16 日以前作成）では reserved-memory がパラメータとして利用できるが、 reserved-memory のデフォルト値は 0byte reserved-memory-percent のデフォルト値は 25% この周辺の AWS 公式ドキュメントは こちら ジョブメドレーでは単一の ElastiCache for Redis インスタンスで運用対象を減らす戦略を取っています（Redis 本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません）。そのため、キャッシュ利用のキーには必ず TTL を設定し、Eviction policy は volatile-lru としています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。 メモリ利用量を SQL で分析する 現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。 この分析作業に便利なのが redis-rdb-tools です。このツールは RDB ファイルの内容をもとにキーごとの byte 値を以下のような CSV に出力することができます（ size_in_bytes は理論値）。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以下のように SQLite 等のデータベースに突っ込むことで手元で SQL を使ってメモリ統計の分析ができるようになります。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりとした分析の流れは 本番環境の daily backup RDB 取得 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです（感覚的には理論値は実測値の 1/2 ぐらいでした）。こちらの詳細の推定ロジックが気になる方は 実装 を確認いただければと思います。 ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。 まとめ ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。 ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。 本記事がみなさまの ElastiCache for Redis 運用ライフの一助になれば幸いです。 また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーが LT スポンサーを務める RubyKaigi2018 にもお邪魔する予定（たまにブースに立っています）ので、そちらでもお会いしましょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org