こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？ WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。 最新の仕様書は https://w3c.github.io/webrtc-stats/ です。 このAPIで取... qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？ WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。 最新の仕様書は https://w3c.github.io/webrtc-stats/ です。 このAPIで取... qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？ WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。 最新の仕様書は https://w3c.github.io/webrtc-stats/ です。 このAPIで取... qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ https://www.wantedly.com/projects/170112 その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 https://www.wantedly.com/companies/medley

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp