みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末に JavaScript AST ことはじめ という発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか 現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体はできるとしても、やはり得意な分野以外で基本原理など含めて把握して開発できるかというと、ちょっと難しいところもあります。しかし、そういった基本原理なんかを知っていると、その言語やツールなどの理解が捗るのは確かですよね。 そんな中、弊社で開発している人間がほぼ全て恩恵を受けているはずなのに、具体的にどんな風に動いているのかが一番分かりにくいであろう Babel ひいては JavaScript AST の話をしたら、まあ興味持って話を聞いてくれるかなーということででこのテーマを選んだ次第です。 どのように伝えるか 自分は JavaScript AST についてとても詳しいわけではないのですが、以前仕事で acorn を使ってコンバータみたいなのを作ったりしていたので、それなりに興味は持っているという人間です。 ですので、どうやって紹介をしようかと悩んだ結果、ほぼ全面的に AST Explore に頼っていくというスタイルにしました。AST Explore は本当に最高ですね。前述の仕事をしていたときはこんな便利なツールはなかったんで、ひたすら AST に変換するコード書いては出来た AST を見て、それをトランスフォームさせて結果と睨めっこして試行錯誤するという毎日でした。 ということで、当日のスライドはこちらになります。 スライドで紹介したデモはそれぞれこちらになります。 https://astexplorer.net/#/gist/82742676286b2dced595ce36cdeb8aae/latest https://astexplorer.net/#/gist/52d871c2f3a8d9cefc68d17badf4f165/latest 今回伝えたかったこと まず、AST が JavaScript の発展にとても寄与しているものだということを知ってもらいたかったため、JavaScript AST の今までの簡単な流れや、現在どのような形で使われているのかの説明をしました。(個人的に Node.js の誕生と JavaScript AST の存在が現在のフロントエンドの発展にとても重要だと思っているので) 最初のうちは聞いてる人も「何の話なんだろ…」感がありましたが、やはり実際に自分が使っているツールなどに使われているという説明をしたあとだと、聞いているメンバーも俄然興味が出てきたという雰囲気になった気がします(当社比)。 AST の文法などは自分が説明するよりは、ちゃんと資料が揃っているので必要な部分以外簡略化しました。逆にちょっと端折りすぎたきらいもありますが、興味を持ったときに何となくでも調べる道標くらいにはなるかなと考えています。 次に知ってもらいたかったのは、やろうと思えば Babel のプラグインなんかも AST で作れちゃいますよということでした。仮にいきなり「Babel プラグイン作りましょう」となったとしても正直あまりピンと来ないと思いますが、どういう原理でプロダクトが動いているのか?が分かると、 babel-handbook などを読んでも理解が進むのではないかと思います。 AST Explore のこと このように今回の発表で全面的に活躍した AST Explore ですが、TechLunch 中でも軽い説明だけで使ってしまったので、使いかたなど簡単にご紹介していきます。 AST Explore とは AST Explore は Felix Kling さんが、2014 年頃から開発しているプロダクトです。 余談ですが、Felix さんは現在 Facebook で働いていらっしゃるようで、 facebook/jscodeshift や reactjs/react-docgen なんかの開発にも携わっていらっしゃる模様。(react-docgen は babylon を使っているようですが) ここまで書いてきた通りに、このツールは色々な言語をコピペするだけで AST をツリー形式で分かりやすく表示したり、トランスフォームさせることができたりするという AST を触るには大変便利なツールです。去年の v2.0 のアップデートにより、セーブすると gist を匿名で作ってくれてリンクが生成されるなどの便利機能が付きました。 プロジェクトの README に書いていますが、パーサだけであれば、かなりパースできるものが多く、また JavaScript / CSS / 正規表現 / Handlebars に関してはトランスフォームまでできるようになっています。 README から抜粋すると以下のような感じです。 AST Explore でパースできるもの CSS: cssom csstree postcss + postcss-safe-parser & postcss-scss rework GraphQL Graphviz: redot Handlebars: glimmer handlebars HTML: htmlparser2 parse5 ICU JavaScript: acorn + acorn-jsx babel-eslint babylon espree esformatter esprima flow-parser recast shift traceur typescript typescript-eslint-parser uglify-js JSON Lua: luaparse Markdown: remark PHP php-parser Regular Expressions: regexp-tree Scala Scalameta SQL: sqlite-parser WebIDL YAML 実験的だったりするけどパースできるもの ES6: arrow functions, destructuring, classes, … ES7 proposals: async/await, object rest / spread, … JSX Typed JavaScript Flow and TypeScript SASS パースしたものをトランスフォームできるもの JavaScript babel (v5, v6) ESLint (v1, v2, v3) jscodeshift tslint CSS postcss Regular Expressions regexp-tree Handlebars glimmer AST Explore の使い方の簡単な解説 サイトにアクセスするとこのような画面になっているはずです。 メイン画面 JavaScript にフォーカスして解説していきますと、左ペインが AST に変換したいソースコード、右ペインが変換後の AST をツリー構造で見せています。 初期表示時に、左ペインのソースコードをクリックすると該当箇所の AST ツリーが展開してハイライトします。また右ペインをポイントするとソースコードの該当箇所がハイライトします。お互いの関係が分かりやすい仕様になっています。 本来 JavaScript AST で生成されるものは JSON オブジェクトになりますが、右ペインの上の Tree と JSON のタブを切りかえることによって AST の表示を変更することができます。 ヘッダー部分 ヘッダーに色々な機能がまとまっています。 初期表示では以下のようになっているはずです。 Snippet 俗にいうファイルメニュー。 新規作成・(gist への)セーブ・(gist の)フォーク・シェアがある JavaScript パースする言語選択 ここで AST にしたい言語を切り替える 選んだ言語によって Transform が使えなくなる acorn パーサ選択 各言語のパーサを切り替える Transform トランスフォーマ選択 選択した言語にトランスフォーマがあれば選択できるようになる こちらを選択すると 2 ペインだったのが 4 ペインになる(後述) default ソースコードなどを書くときのキーバインド選択 default / Vim / Emacs / Sublime の 4 種類がある うれしみがあります ? ヘルプ GitHub の README に飛ばされるだけです… JavaScript のトランスフォーム 先程説明したトランスフォームを選ぶと、メインの画面が 4 画面になります。 今までの ソースコード と AST ツリー は変わりませんが、下に 2 つペインが追加されます。 左下がトランスフォーマコード、右下がトランスフォームした後のソースコードとなっています。 左下のトランスフォーマを色々触っていくと左上のソースコードが変換されて、右下に表示されるという流れですね。 以下 JavaScript コードのトランスフォームする際の Tips です jscodeshift を選択すると Ctrl + Space で jscodeshift の補完が効くようになります babel-plugin-macro を選ぶとトランスフォーマのコード自体がそのまま babel-plugin として使えるようになるので、プラグイン作るときに捗るはずです まとめ 後で参加メンバーに聞いてみましたが、伝えたかったことは、ちゃんと伝わっていた様子だったので安心しました。最後の Vue.js の v1 から v2 のマイグレーションのデモは紹介した結果、JavaScript AST 便利そうという感触になったと思います。 現在弊社のプロダクトで、JavaScript AST をガッツリと使うようなプロジェクトはないのですが、Babel などは全プロダクトで使用しており、結構プラグインを多用しているところもあるので、いざというときの基礎知識として覚えておいて損はないはずです。 こういった部分の勉強も欠かさず続けていきたいと改めて思う機会にもなりました。 弊社の開発文化など気になる方は、こちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは！開発本部のエンジニア・後藤です。 メドレーは 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 への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 https://www.wantedly.com/companies/medley 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 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 への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！ 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 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

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「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