TechLunch で COBOL と ORCA について話しました 開発本部の竹内です。病気事典 MEDLEY の開発を担当しております。子どもが絶賛イヤイヤ期中です。 さて先日、TechLunch という社内勉強会にて COBOL と ORCA についての発表を行いましたので、その紹介をさせていただきたいと思います。 はじめに COBOL とは？ ORCA とは？の前に、「なぜ今回このテーマを選んだか」について簡単に説明させてください。 株式会社メドレーでは「医療ヘルスケア分野の課題を解決する」ために各サービスの開発・運営を行っています。 しかし、「医療ヘルスケア分野」のサービス開発・運営を行っていると言っても、実際の開発現場では一般的な Web アプリケーションや スマートフォン アプリケーションの開発を行うことが多々あります。 そのため、日々の仕事において「医療ヘルスケア分野」で業務を行っていると意識しないこともあります。 せっかく「医療 ×IT」の会社にいるわけなので、エンジニアとして医療に深く関わるソフトウェアについて勉強してみるのも面白いのではないか、と思ったことがテーマの選択につながっています。 また、医療ヘルスケア分野で OSS として公開されている代表的なものとして ORCA の「日医標準レセプトソフト」がある、というのもテーマ選択の理由の一つです。 どんなソフトウェアにせよそれが OSS であれば、コードが公開されているため勉強を始めるハードルはかなり下がるため、です。 ORCA とは ORCA プロジェクトとは、医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた 日本医師会 の研究事業プロジェクトです。 ORCA Project： ORCA プロジェクトの概要 ORCA とは 日本医師会 のプロジェクトで、国民医療を改善するために医療情報の効率化・標準化を推進するために、医師・医療関係機関が無料で利用・改良できる OSS を配布しています。 現在、診療報酬を請求するための専用コンピュータ（＝レセコン）は、全国の 医療機関 の内８割以上が使用しているそうです。 ORCA プロジェクトでは「日医標準レセプトソフト（＝日レセ）」という OSS が公開されています。 OSS なのでもちろんコードは公開されており、その他の技術情報も下記リンク先に詳細が掲載されています。 ORCA Project： 技術情報 COBOL とは さて、上記リンク先を見いくと日医標準レセプトソフトのコードは CVS で公開されており、その中を見てみると COBOL のコードがあることがあわかります。 個人的に COBOL については、「名前は聞いたことあるけど、文法など詳細は知らない割になぜか良い印象を持っていない」という状態でした。 レセコンのロジックを勉強するにあたり、ついでに未知の言語である COBOL も勉強してみよう、という軽いノリで調べはじめました。 勉強会では COBOL の基本的な文法にフォーカスして紹介しています。 また、今回は COBOL の実行環境として Docker を利用しています。 COBOL による HELLO, WORLD IDENTIFICATION DIVISION . PROGRAM-ID . HELLO_WORLD . ENVIRONMENT DIVISION . DATA DIVISION . PROCEDURE DIVISION . DISPLAY "Hello, COBOL" . STOP RUN . ORCA のコードについて 上述の通り、 ORCA （日レセ）のコードは CVS で管理されているため、 Mac では次のようにしてコードを取得できるかと思います。 # 参考：https://www.orca.med.or.jp/receipt/tec/cvs-jma-receipt.html\# リポジトリ取得 $ brew install cvs $ curl https://ftp.orca.med.or.jp/pub/data/receipt/tec/orcacvs > ~/bin/orcacvs $ chmod +x ~/bin/orcacvs $ cvs -d :ext:anoncvs@cvs.orca.med.or.jp:/cvs co jma-receipt 実際の COBOL のコードは cobol という ディレクト リに入っています。 https://cvs.orca.med.or.jp/cgi-bin/cvsweb/jma-receipt/cobol/ 見てみると、ファイルを開いてコメントを確認するまでどれがどういう用途なのかよくわかりませんでした。 ファイル内のコメントにある「 コンポーネント 名」と cvsweb の URL を対応付けた markdown を作成しましたので、興味がある方は見てみてください。 orca-jma-receipt-study/cobol.md at master · ise/orca-jma-receipt-study Contribute to ise/orca-jma-receipt-study development by creating an account on GitHub. github.com まとめ TechLunch で ORCA と COBOL について紹介しました。 軽い気持ちで調べはじめましたが、 「レセコンが OSS で配布されている」ということにまず衝撃を受け、 「 ORCA （日レセ）のコードが CVS で公開されている」ということにも衝撃を受け、 「コードが COBOL である」ということにさらに衝撃を受けました。 が、同時に OSS が日本の医療を支えていることに胸が熱くなりました。技術スタックが古くとも、とても素晴らしいことだと思いました。 また、リニューアル PJ もあるようで、今後の動向が興味深いですね。 ORCA 次期 FW 開発の現状 （少し古い資料ですが） COBOL についても、調べはじめるとなかなかに興味深い言語でしたが、やはり基本文法を理解しただけではレセコンのコードを読んで理解するまでには至りませんでした。。発表資料でも触れましたが、日レセを構成する ミドルウェア である MONTSUQI についても、ある程度理解する必要があると感じました（俺たちの戦いはこれからだ、、） さて、医療に関わるソフトウェア＆（個人的に）未知の技術である COBOL に触れ、心が豊かになったところで今回のブログを締めさせていただきたいと思います。 ここまでお読み下さり、どうもありがとうございました。 ※勉強会資料は下記 speakerdeck.com 最後に メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

TechLunch で COBOL と ORCA について話しました 開発本部の竹内です。病気事典 MEDLEY の開発を担当しております。子どもが絶賛イヤイヤ期中です。 さて先日、TechLunch という社内勉強会にて COBOL と ORCA についての発表を行いましたので、その紹介をさせていただきたいと思います。 はじめに COBOL とは？ ORCA とは？の前に、「なぜ今回このテーマを選んだか」について簡単に説明させてください。 株式会社メドレーでは「医療ヘルスケア分野の課題を解決する」ために各サービスの開発・運営を行っています。 しかし、「医療ヘルスケア分野」のサービス開発・運営を行っていると言っても、実際の開発現場では一般的な Web アプリケーションや スマートフォン アプリケーションの開発を行うことが多々あります。 そのため、日々の仕事において「医療ヘルスケア分野」で業務を行っていると意識しないこともあります。 せっかく「医療 ×IT」の会社にいるわけなので、エンジニアとして医療に深く関わるソフトウェアについて勉強してみるのも面白いのではないか、と思ったことがテーマの選択につながっています。 また、医療ヘルスケア分野で OSS として公開されている代表的なものとして ORCA の「日医標準レセプトソフト」がある、というのもテーマ選択の理由の一つです。 どんなソフトウェアにせよそれが OSS であれば、コードが公開されているため勉強を始めるハードルはかなり下がるため、です。 ORCA とは ORCA プロジェクトとは、医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた 日本医師会 の研究事業プロジェクトです。 ORCA Project： ORCA プロジェクトの概要 ORCA とは 日本医師会 のプロジェクトで、国民医療を改善するために医療情報の効率化・標準化を推進するために、医師・医療関係機関が無料で利用・改良できる OSS を配布しています。 現在、診療報酬を請求するための専用コンピュータ（＝レセコン）は、全国の 医療機関 の内８割以上が使用しているそうです。 ORCA プロジェクトでは「日医標準レセプトソフト（＝日レセ）」という OSS が公開されています。 OSS なのでもちろんコードは公開されており、その他の技術情報も下記リンク先に詳細が掲載されています。 ORCA Project： 技術情報 COBOL とは さて、上記リンク先を見いくと日医標準レセプトソフトのコードは CVS で公開されており、その中を見てみると COBOL のコードがあることがあわかります。 個人的に COBOL については、「名前は聞いたことあるけど、文法など詳細は知らない割になぜか良い印象を持っていない」という状態でした。 レセコンのロジックを勉強するにあたり、ついでに未知の言語である COBOL も勉強してみよう、という軽いノリで調べはじめました。 勉強会では COBOL の基本的な文法にフォーカスして紹介しています。 また、今回は COBOL の実行環境として Docker を利用しています。 COBOL による HELLO, WORLD IDENTIFICATION DIVISION . PROGRAM-ID . HELLO_WORLD . ENVIRONMENT DIVISION . DATA DIVISION . PROCEDURE DIVISION . DISPLAY "Hello, COBOL" . STOP RUN . ORCA のコードについて 上述の通り、 ORCA （日レセ）のコードは CVS で管理されているため、 Mac では次のようにしてコードを取得できるかと思います。 # 参考：https://www.orca.med.or.jp/receipt/tec/cvs-jma-receipt.html\# リポジトリ取得 $ brew install cvs $ curl https://ftp.orca.med.or.jp/pub/data/receipt/tec/orcacvs > ~/bin/orcacvs $ chmod +x ~/bin/orcacvs $ cvs -d :ext:anoncvs@cvs.orca.med.or.jp:/cvs co jma-receipt 実際の COBOL のコードは cobol という ディレクト リに入っています。 https://cvs.orca.med.or.jp/cgi-bin/cvsweb/jma-receipt/cobol/ 見てみると、ファイルを開いてコメントを確認するまでどれがどういう用途なのかよくわかりませんでした。 ファイル内のコメントにある「 コンポーネント 名」と cvsweb の URL を対応付けた markdown を作成しましたので、興味がある方は見てみてください。 orca-jma-receipt-study/cobol.md at master · ise/orca-jma-receipt-study Contribute to ise/orca-jma-receipt-study development by creating an account on GitHub. github.com まとめ TechLunch で ORCA と COBOL について紹介しました。 軽い気持ちで調べはじめましたが、 「レセコンが OSS で配布されている」ということにまず衝撃を受け、 「 ORCA （日レセ）のコードが CVS で公開されている」ということにも衝撃を受け、 「コードが COBOL である」ということにさらに衝撃を受けました。 が、同時に OSS が日本の医療を支えていることに胸が熱くなりました。技術スタックが古くとも、とても素晴らしいことだと思いました。 また、リニューアル PJ もあるようで、今後の動向が興味深いですね。 ORCA 次期 FW 開発の現状 （少し古い資料ですが） COBOL についても、調べはじめるとなかなかに興味深い言語でしたが、やはり基本文法を理解しただけではレセコンのコードを読んで理解するまでには至りませんでした。。発表資料でも触れましたが、日レセを構成する ミドルウェア である MONTSUQI についても、ある程度理解する必要があると感じました（俺たちの戦いはこれからだ、、） さて、医療に関わるソフトウェア＆（個人的に）未知の技術である COBOL に触れ、心が豊かになったところで今回のブログを締めさせていただきたいと思います。 ここまでお読み下さり、どうもありがとうございました。 ※勉強会資料は下記 speakerdeck.com 最後に メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

TechLunch で COBOL と ORCA について話しました 開発本部の竹内です。病気事典 MEDLEY の開発を担当しております。子どもが絶賛イヤイヤ期中です。 さて先日、TechLunch という社内勉強会にて COBOL と ORCA についての発表を行いましたので、その紹介をさせていただきたいと思います。 はじめに COBOL とは？ ORCA とは？の前に、「なぜ今回このテーマを選んだか」について簡単に説明させてください。 株式会社メドレーでは「医療ヘルスケア分野の課題を解決する」ために各サービスの開発・運営を行っています。 しかし、「医療ヘルスケア分野」のサービス開発・運営を行っていると言っても、実際の開発現場では一般的な Web アプリケーションや スマートフォン アプリケーションの開発を行うことが多々あります。 そのため、日々の仕事において「医療ヘルスケア分野」で業務を行っていると意識しないこともあります。 せっかく「医療 ×IT」の会社にいるわけなので、エンジニアとして医療に深く関わるソフトウェアについて勉強してみるのも面白いのではないか、と思ったことがテーマの選択につながっています。 また、医療ヘルスケア分野で OSS として公開されている代表的なものとして ORCA の「日医標準レセプトソフト」がある、というのもテーマ選択の理由の一つです。 どんなソフトウェアにせよそれが OSS であれば、コードが公開されているため勉強を始めるハードルはかなり下がるため、です。 ORCA とは ORCA プロジェクトとは、医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた 日本医師会 の研究事業プロジェクトです。 ORCA Project： ORCA プロジェクトの概要 ORCA とは 日本医師会 のプロジェクトで、国民医療を改善するために医療情報の効率化・標準化を推進するために、医師・医療関係機関が無料で利用・改良できる OSS を配布しています。 現在、診療報酬を請求するための専用コンピュータ（＝レセコン）は、全国の 医療機関 の内８割以上が使用しているそうです。 ORCA プロジェクトでは「日医標準レセプトソフト（＝日レセ）」という OSS が公開されています。 OSS なのでもちろんコードは公開されており、その他の技術情報も下記リンク先に詳細が掲載されています。 ORCA Project： 技術情報 COBOL とは さて、上記リンク先を見いくと日医標準レセプトソフトのコードは CVS で公開されており、その中を見てみると COBOL のコードがあることがあわかります。 個人的に COBOL については、「名前は聞いたことあるけど、文法など詳細は知らない割になぜか良い印象を持っていない」という状態でした。 レセコンのロジックを勉強するにあたり、ついでに未知の言語である COBOL も勉強してみよう、という軽いノリで調べはじめました。 勉強会では COBOL の基本的な文法にフォーカスして紹介しています。 また、今回は COBOL の実行環境として Docker を利用しています。 COBOL による HELLO, WORLD IDENTIFICATION DIVISION . PROGRAM-ID . HELLO_WORLD . ENVIRONMENT DIVISION . DATA DIVISION . PROCEDURE DIVISION . DISPLAY "Hello, COBOL" . STOP RUN . ORCA のコードについて 上述の通り、 ORCA （日レセ）のコードは CVS で管理されているため、 Mac では次のようにしてコードを取得できるかと思います。 # 参考：https://www.orca.med.or.jp/receipt/tec/cvs-jma-receipt.html\# リポジトリ取得 $ brew install cvs $ curl https://ftp.orca.med.or.jp/pub/data/receipt/tec/orcacvs > ~/bin/orcacvs $ chmod +x ~/bin/orcacvs $ cvs -d :ext:anoncvs@cvs.orca.med.or.jp:/cvs co jma-receipt 実際の COBOL のコードは cobol という ディレクト リに入っています。 https://cvs.orca.med.or.jp/cgi-bin/cvsweb/jma-receipt/cobol/ 見てみると、ファイルを開いてコメントを確認するまでどれがどういう用途なのかよくわかりませんでした。 ファイル内のコメントにある「 コンポーネント 名」と cvsweb の URL を対応付けた markdown を作成しましたので、興味がある方は見てみてください。 orca-jma-receipt-study/cobol.md at master · ise/orca-jma-receipt-study Contribute to ise/orca-jma-receipt-study development by creating an account on GitHub. github.com まとめ TechLunch で ORCA と COBOL について紹介しました。 軽い気持ちで調べはじめましたが、 「レセコンが OSS で配布されている」ということにまず衝撃を受け、 「 ORCA （日レセ）のコードが CVS で公開されている」ということにも衝撃を受け、 「コードが COBOL である」ということにさらに衝撃を受けました。 が、同時に OSS が日本の医療を支えていることに胸が熱くなりました。技術スタックが古くとも、とても素晴らしいことだと思いました。 また、リニューアル PJ もあるようで、今後の動向が興味深いですね。 ORCA 次期 FW 開発の現状 （少し古い資料ですが） COBOL についても、調べはじめるとなかなかに興味深い言語でしたが、やはり基本文法を理解しただけではレセコンのコードを読んで理解するまでには至りませんでした。。発表資料でも触れましたが、日レセを構成する ミドルウェア である MONTSUQI についても、ある程度理解する必要があると感じました（俺たちの戦いはこれからだ、、） さて、医療に関わるソフトウェア＆（個人的に）未知の技術である COBOL に触れ、心が豊かになったところで今回のブログを締めさせていただきたいと思います。 ここまでお読み下さり、どうもありがとうございました。 ※勉強会資料は下記 speakerdeck.com 最後に メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは、開発本部エンジニア平木です。 弊社では定例で TechLunch という社内勉強会を開いています。今回は自分が担当になったので、最近の動向も含めて ECMAScript について話をしました。 なぜ ECMAScript について話そうと思ったのか? ご存知の方も多いでしょうが、 ECMAScript とは JavaScript の仕様になります。 ここからは個人的な印象になりますが、つい数年前までは特にフロントエンド開発をする人でも仕様のことを意識しなくてもあまり問題はなかったと思います。 しかし、Babel や TypeScript などが普及しだしてきたあたりから、ブラウザの実装に関係なく ECMAScript で提案されている仕様が使えるようになり、段々と ECMAScript について知っておいた方が開発効率が上がる…ということになってきたかと思います。 最近ですと、特に Babel を使う前提の React.js などが一般に使われてきていますので、そういった開発をするときに ECMAScript の仕様がどのように決まって次の仕様にはどういった機能が取り込まれるのかを知っておくと開発がしやすくなるのではないかと考えています。 弊社でもちらほらと、ECMAScript2015 以降を使うようになってきているという事情もあり、ここらで情報が追いやすくなってきている ECMAScript について興味を持ってもらおうという意図で題材に選びました。 話す内容で考えたこと このような思いから、題材は決まったのですが、いきなり ECMAScript について話しだしても全然わからないよねということになります。 以前に Meguro.es #1 というイベントで ECMAScript について LT をさせてもらった のですが、イベントの性質上前提をすっ飛ばして話した感じでした。 しかし、弊社のエンジニア陣は今でこそフロントエンドも実装していますが元々はバックエンドなどフロントエンド以外出身のエンジニアが多いので、本題のなぜ ECMAScript の次の仕様が追いやすくなったしキャッチアップしていこう!という点がピンとこない可能性があります。 前提としてそもそも JavaScript の歴史や、 ECMAScript が策定される経緯などから話さないといけないかも…と色々盛り込んだ話をしたのですが、結果としてはちょっと本題がボヤけてしまった感じがあり反省しています…。 スライドはこちらになります。 スライドには入れられなかった部分 時間の都合で話したかったけど入っていないことを 2 点ほど。 Babel について TechLunch の発表では、構成上入れていなかったのですが、弊社のプロダクトでいうと JavaScript を結局は Babel を使ってトランスパイルするという形がほとんどです。 基本の ES2015 の機能については Learn ES2015 · Babel や yosuke-furukawa/tower-of-babel なんかで覚えることができると思います。 しかし、極端な例でいうと Babel の プラグイン の Stage 0 preset · Babel を使ったりするとさらに便利(かもしれない)機能が使えるようになります。この プラグイン で使える機能は何か?というのを調べるとなると、やはり tc39/proposals などを見たほうが早いということになります。 次にどんな機能が来るなどの情報はこの発表の内容などを知ってるとキャッチアップしやすくなると思います。 詳しい情報源について+α 参考情報として載せたなかで個人的に 早い・分かりやすい・詳しい を兼ねそなえているのが Dr. Axel Rauschmayer の 2ality – JavaScript and more かなと思っています。 英語が苦でなければこの人のブログを読んでるだけで実用上問題ないくらいに ECMAScript の動向についていけます。 この方の JavaScript / ECMAScript 関連の本 もすばらしいので、これまた英語が苦でなければぜひ読んでください。 ちなみにこの方は ES.next News: 5 ECMAScript.next links, every week という メーリングリスト も運営しておりこちらは粒度としては 1 週間に 1 回になるんである意味読みやすい情報かもしれません。 日本語ですと、 ECMAScript だけではないですがやっぱり azu さんの JSer.info がよいかと思います。 まとめ ECMAScript についての勉強会を開催したお話でした。メドレーでは、 ECMAScript の仕様読むの大好物!というような方もぜひ来ていただきたいと思っています!! また 4/19(水)に筆者が携わっている CLINICS について話すイベントを開催します。 mednight.connpass.com フロントエンドのことについて話す予定ですので、ご興味あればぜひご参加ください! お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

オンライン診療アプリ「 CLINICS 」を開発している田中です。 本日は、メドレー開発本部にて隔週で行われている勉強会（TechLunch）で、今後の バッチ処理 構成の 1 つとして活用できそうな AWS サービスの紹介を行ったので、その一部を紹介したいと思います。 背景と勉強会の目的 メドレーでの バッチ処理 メドレーの各プロダクトは環境として主に AWS を使用しており、いわゆる「 バッチ処理 」（時間起動でのデータ一括処理系）については、スケジューラとして使用している Jenkins からバッチ用 EC2 インスタンス 上の バッチ処理 をキックする、という構成が多いです。 （短時間で完了し、ワークフロー自体シンプルなバッチについては、スケジューラに Lambda を利用する構成も増えてきました） その他、SQS を用いたキューイング処理、 Kinesis /Lambda を使用したログストリーミング処理など様々な構成で動いています。 勉強会の目的 現状、プロダクトを運用する上で バッチ処理 で何か課題があるかと言えば特には無いのですが、下記を目的として勉強会を行いました。 そもそも バッチ処理 とは？という整理 バッチ処理 構成の新しい選択肢としてのインプット 今後各プロダクトを跨ぐ共通基盤システムなどで バッチ処理 が必要になった場合など、出来るだけ人の手間を減らしたい場合に備え、選択肢の 1 つとしてバッチ向けサービス（ AWS Batch、Step Functions）の紹介を行いました。 また、広義の意味での バッチ処理 /狭義の意味での バッチ処理 という整理で、一括系処理系、ストリーミング/キューイングなどの（ほぼ）リアルタイム系の違いやよくある構成についての説明も行いました。 勉強会の内容 メドレーでは様々なバックグラウンドをもったエンジニアが集まっており、フロントエンドやネイティブは得意だけどサーバーサイド/インフラはまだ慣れていないエンジニア向けに、そもそも バッチ処理 とは？という内容から始めました。 バッチ処理 の概要、よくあるシステム構成 バッチ処理 設計時のポイント ここ最近のバッチ関連の流れ（リアルタイム化） 各プロダクトのバッチ構成の例 次に、今後使えそうな AWS のサービスとして AWS Batch と Step Functions の概要について説明しました。 AWS Re:Invent 2016 で発表された AWS の batch 処理系に使える新サービス AWS Batch フルマネージド型の バッチ処理 実 行基 盤 必要なリソース（CPU、メモリ etc）を定義すれば、 AWS が必要に応じて ECS 上で実行（ インスタンス タイプ、分散用に台数確保） ジョブとして登録したアプリやコンテナイメージを実行 Step Functions Lamba などの複数アプリをワークフローとして定義、実行（ビジュアル化） 今までは Lambda to Lambda や、SQS を介すなど自分で考慮必要だったワークフロー（分岐、繰り返しなど）を JSON で定義しサービス化 ※ 発表資料は以下 最後に、簡単にですが Step Functions を実際に試した内容と、個人的な感想を共有しました。 Pros 既存の Lambda をそのまま使用できる フロー定義や実行結果がビジュアルで確認できる 同じ Lambda を別々の State Machine で使えるので汎用性、再利用性が高まる Cons ワークフローが複雑になると、タスクの JSON 定義がけっこう手間（Step Functions に限った話ではないですが、、、） トランザクション 的な管理、設計の勘所がけっこう必要になりそう まとめ メドレー開発本部の技術勉強会（TechLunch）で発表した内容の一部を紹介しました。 メドレーでは各技術の選択基準として、適材適所という考えを大事にしています。そのため、新技術/新サービスを使用すればいいと言う訳ではなく、今回の内容に関連して言えば、あえてベーシックにバッチ インスタンス を立てて、という構成も適材適所であれば問題ないと考えています。 適材適所を効果的に行うためには、日々、新技術も情報として押さえ蓄積していく事が重要だと思うので、INPUT の一環として今後も「TechLunch」を更に活用していきたいと思います。 お知らせ CTO 平山のブログが本日公開となりました。 記念すべき第一回目は、「医療 × インターネットの未来」がテーマ。 ぜひ読んでみてくださいね。 toppa.medley.jp また、CTO 平山とのランチ会を定期開催予定です。 ご興味ある方はぜひエントリーください！ www.wantedly.com 求人情報 メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

医療介護の求人サイト「 ジョブメドレー 」の開発を担当している後藤です。 メドレー開発本部にて隔週で行われている勉強会（TechLunch）で メタプログラミング Ruby をベースに メタプログラミング Ruby 入門について発表したのでその一部を紹介したいと思います。 メドレーと Ruby 弊社では「 CLINICS 」、「 ジョブメドレー 」、「 介護のほんね 」と複数のプロダクトで Ruby on Rails を利用しています。 スタートアップでそこまでエンジニアの数が多くないなか、エンジニアが最大限にプロダクトにコミットするために、もともとのバックグラウンドがフロントエンドエンジニアだったり、ネイティブアプリエンジニアだったりする方も Ruby on Rails のコードを書いています。 Ruby on Rails はとても便利な フレームワーク で、周辺の便利なライブラリや解説記事が整っていることもあり、必要な機能は検索すればあまり中身を理解せずとも実装できてしまったりもします。ただ、何か問題があった時のために利用している フレームワーク の処理を把握しておくことはとても重要です。そして、 フレームワーク の ソースコード を読み解くにはやはり Ruby の言語仕様の知識が重要になってきます。 また、 Ruby の言語仕様、そして使っている フレームワーク の深い理解があることでよりメンテナンスしやすい設計・実装がしやすくなるのも事実だと思います。 こういった背景のもと、社内のエンジニアの Ruby に対する知見を深めることはとても価値があると感じ、「 メタプログラミング Ruby 」をベースに メタプログラミング Ruby 入門の勉強会を開催しました。 メタプログラミング Ruby 入門 今回は メタプログラミング 入門ということで Ruby で メタプログラミング をする上で必要な Ruby の言語仕様の話と一つの例として method_missing の話を取り上げました。 Ruby のオブジェクトモデル この Ruby のオブジェクトモデルという言葉は「 メタプログラミング Ruby 」から拝借しています。本の中では「このメソッドはどのクラスに所属するものなのか？」「このモジュールをインクルードしたら何が起きるのか」といった質問の答えが見つかる場所と記載しています。このオブジェクトモデルには以下のようなルールが存在します。 オブジェクトは 1 種類しかない。それが通常のオブジェクトかモジュールになる。 モジュールは 1 種類しかない。それが通常のモジュール、クラス、特異クラスのいずれかになる。 メソッドは 1 種類しかない。メソッドはモジュール（大半はクラス）に住んでいる。 すべてのオブジェクトは（クラスも含めて）「本物のクラス」を持っている。それが通常のクラスか特異クラスである。 すべてのクラスは（BasicObject を除いて）ひとつの祖先（ スーパークラス かモジュール）を持っている。つまり、あらゆるクラスが BasicObject に向かって 1 本の継承チェーンを持っている。 オブジェクトの特異クラスの スーパークラス は、オブジェクトのクラスである。クラスの特異クラスの スーパークラス はクラスの スーパークラス の特異クラスである。 メソッドを呼び出すときは、 Ruby はレシーバの本物のクラスに向かって「右へ」進み、継承チェーンを「上へ」進む。 Ruby のメソッド探索について知るべきことは以上だ。 ( メタプログラミング Ruby 第 2 版 より) BasicObject#method_missing Ruby でメソッド呼び出しを行った際のフローは以下になります。 Ruby はレシーバーの本物のクラスに向かってメソッド探索を始める 継承チェーンを BasicObject まで辿っても呼び出したメソッドが見つからなかった場合、 Ruby はレシーバーの method_missing を呼び出す メソッド探索で method_missing が見つからなかった場合、BasicObject#method_missing が呼び出され、例外が投げられる この仕組みをうまく使って、BasicObject#method_missing が呼び出される前に自前の method_missing メソッドを呼び出すようにして動的にメソッドを定義したり動的な振る舞いをオブジェクトに加えたりすることができるのです。 勉強会の様子 ここまでお話しした内容を含め、勉強会では以下の内容を発表しました。 発表資料はこちら 発表時の個人的な裏テーマとして「あまり Ruby が得意でない方に メタプログラミング Ruby を読みたくなるようにさせる」というものを設定していましたが、実際の発表後にちらほら メタプログラミング Ruby の話が出ていたので発表した甲斐がありました。 まとめ 今回はメドレー開発本部の技術勉強会（TechLunch）で発表した内容を紹介しました。 勉強会では、まず Ruby の言語要素とメソッド実行の理解を深め、その上で BasicObject#method_missing を理解し、それを使った gem のコードを読み進めました。 実際に Ruby での メタプログラミング に触れることで Ruby への知見が深めていけたかと思います。 メドレー開発本部で実施している「TechLunch」での発表内容は今後も定期的に紹介していくので、是非メドレーブログをチェックしてみてください。 お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp