TECH PLAY

株式会社メドレー

株式会社メドレー の技術ブログ

1363

こんにちは。エンジニアの平木です。 メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア 4 名が新卒社員として入社しました。 現在、新卒メンバーは 6 ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、**初めての新卒研修をどのような視点で計画・実行していったか?**を書いていきたいと思います。 2019 年度新卒入社メンバー 新卒研修を決めるまでやったこと 研修の大枠決定 カリキュラムの大枠を決めるため、まず CTO の平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。 決めたことは、以下3点です。 入社後の導入部分 社会人としてのビジネスマナーや考え方の基礎を学ぶ プロダクト開発をする上で必要になる基礎を学ぶ 会社の事業内容を理解する OJT をメインとした各チームへの仮配属 新卒社員へのフォローアップ メンターや部長との定期報告会 半年後に役員陣への成果報告会 エンジニアとして価値を出していくため必要な**「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」**という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。 こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。 toppa.medley.jp toppa.medley.jp 情報収集 社内エンジニアへのヒアリング 前職で新卒研修を受けたことがある社内の 20 代~30 代のエンジニア 4 人を対象に、研修内容についてヒアリングしました。 ヒアリングしたポイントは 研修の期間 研修全体の流れ 各研修メニューの内容 OJT はどういった形で受けたか 研修を受けての感想 など。各社・各年代で個性が出るなという印象を持ちました。 やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。 ネットでの情報収集 ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。 しかし、内容としては**「アプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないな**という印象を持ちました。 そんな中、各社の新卒研修エントリが Gist にまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。 研修資料まとめ.md GitHub Gist: instantly share code, notes, and snippets. gist.github.com 研修メニュー決定 研修の詳細メニュー ここまでの過程を踏まえ研修メニューを筆者が考え、CTO や開発部部長の田中・副部長の稲本と刷り合わせをしていきました。 結果として、以下のメニュー構成でいくことになりました。 オリエンテーション **[座学]**社会人研修や会社全般の知識の習得を目的にする 開発基礎研修 **[座学]**Web アプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする 開発実践研修 **[OJT]**社内向けに Web アプリケーションを開発し、チーム開発を実践することを目的にする 開発部 OJT **[OJT]**稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする 事業部 OJT **[OJT]**ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする 特に事業部 OJT は新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。 メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。 新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。 実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験 してもらうために、この事業部 OJT をメニューに組み込みました。 研修期間 研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全 6 ヶ月という研修期間を定めました。 オリエンテーション・開発基礎研修・開発実践研修 2 ヶ月 期間中、午前:開発基礎、午後:開発実践 開発部 OJT ・事業部 OJT 4 ヶ月 事業部 OJT は期間中に 2 週間 x 2 つの事業部で実施 メンター 研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように 1 人につき 1 人のメンターを付けています。社会人経験が 3 年以上ある社員をメンターとしました。 最初の 2 週は毎日 1on1 を 15 分程度行ない、以降は毎週金曜日に 1 時間の 1on1 を実施。 また、メンター同士の交流として、2 週に 1 度メンターの共有会を開き、相談や近況報告を行いました。 メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。 研修メニュー内容 各研修内容のご紹介です。 オリエンテーション オリエンテーションは 外部ビジネス研修 コンプライアンス研修 セキュリティ研修 開発環境の整備 開発ツールの解説 がメインです。 Mac を渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。 オリエンテーションは約 1 週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらう ことができました。 開発基礎研修 大きく 2 部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。 もう一つの部では書籍の輪読をしました。この輪読は、Web サービスの基本の仕組みと、Web サーバ自体を支える OS である Linux の基本を覚えてもらいたいという趣旨で開催しました。 メドレーについて こちらの部では CTO 平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。 その後は、 ジョブメドレー ・ CLINICS ・ 介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。 メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。 この段階でまずこうした メドレーでエンジニアとして働くとはどういうことなのか という知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030 年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。 導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。 輪読会 座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、 プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのは ドワンゴさんの 2016 年の研修の記事 です。 輪読で使用する本の選定は悩んだのですが、弊社で使っている Ruby や Ruby on Rails のことや、JavaScript などの技術より、基本となる Web 自体についての知識や、Web サーバで使う Linux の事などを習得してもらいたいということを考えて以下の 2 冊で輪読を行いました。 Web を支える技術 ── HTTP,URI,HTML,そして REST(WEB+DB PRESS plus シリーズ) Go ならわかるシステムプログラミング 「Web を支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。 議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。 まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすること を狙いとしています。 最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。 対して「Go ならわかるシステムプログラミング」については 新卒メンバーに章を割り当てて、各自講師をしてもらいました。 元々レポートを 3 回発表することを予定していたので、本の内容を読んできちんと理解した上で、 他人へ伝える力を養う ことをサブ目標にしています。 さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていない Go 言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。 開発実践 開発実践は上記の開発基礎と並行して午後から実施しました。 1 日の午前が開発基礎、午後が開発実践というスケジュールです。 実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。 題材は**「メドレーの使い方に合ったビルの予約システムを作る」**というものです(以前 SmartHR さんが同じビルだったので少しアプローチが違いますが ブログ に書いてました)。 メドレーでの業務開発と同じ形式で ユーザーからの要望をヒアリング 要件定義 開発計画の策定 システム設計 チームで分担してながらの開発 ベータ版としてリリースしたものをブラッシュアップ 実稼働するための環境整備をしながらリリースする という一連のプロセスで開発しました。 「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々 MTG や PR をレビューしながら、アドバイスをするという形式で行いました。 新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。 チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。 途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという 開発のリアルを経験できた のは次の OJT に活きたと思います。 余談ですが、こちらの元々のシステムを調査する上で「Web を支える技術」の知識が早速役に立つという場面が多く、やはり 基本は大事だな、と思った 次第です。 開発部 OJT 基礎研修が終わってから、既存サービスにジョインしての OJT 実施となりました。 ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。 メンバーによってはここで時間を取って Ruby on Rails について習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。 事業部 OJT 開発部 OJT の途中で 2 週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部 OJT を行いました。 **どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?**というのをこの時期に体験してもらうことが目的です。 研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。(ありがとうございます!) 実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを 2 週間かけて新卒メンバーに体験してもらいました。 この後に実際**「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想**をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。 レポート発表 それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。 ひたすら研修内容をこなしていくという形になりがちなので、 振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したい という目的です。 また、メドレーでは ドキュメントドリブンで開発に限らず全社員が Confluence でドキュメントを書いていく文化 なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。 レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。 最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的 です。 最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。 まとめ メドレーで初の新卒研修は以上のような形で終わることができました。 かなりのハードスケジュールだったとか、開発部 OJT をもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが 10 月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。 来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した**「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」**という部分はズラさずに実施していければと思います。 長々とお付き合いいただきありがとうございました。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 https://github.com/WICG/badging/blob/master/explainer.md#the-api Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。 Badging API とは Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。 ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、 Fugu というプロジェクトで実現に向けて動いている API の 1 つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定して API を利用できるようにする仕組みのことで、正式リリース前に API に対する有用なフィードバックを受け取ることができるものです。 この API の最新の概要や仕様については、 WICG が Github に Badging API のリポジトリ を用意しているので、そこで確認することができます。 WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3C のグループの 1 つです。 提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。 badging/explainer.md at main · w3c/badging Badging API. Contribute to w3c/badging development by creating an account on GitHub. github.com Badge を window オブジェクトのメンバとして持つ Badge には 2 つのメソッドが存在する Badge.set() Badge.clear() Badge.set(5) のように set() に整数を渡してバッジ上に数字を表示する 単に Badge.set() で呼び出すとフラグとしてバッジを表示する Badge.set(5, { scope: ‘/baz’ }) のようにオプションを渡して特定のスコープ配下で表示されるように指定できる オプションでスコープが指定されてない場合、スコープは / になる ローカル環境で試す 実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。 API 自体は非常にシンプルなので、PWA のアプリを用意してインストールするだけで簡単に試すことができます。 インストールされていないウェブアプリでも、タブの favicon 上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。 最初に API を利用可能な状態にする必要がありますが、上述の通り API 自体が現在 Origin Trials の段階なので、Origin Trials の利用申請を行うかローカル環境であれば chrome://flags で実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。 今回はローカル環境で試すだけなので、chrome://flags から enable-experimental-web-platform-features を有効にしておきます。 実験的な機能を利用可能にしたことで Badging API 自体は利用可能になりますが、 window.Badge として利用可能になっているのではなく、Origin Trials の段階では Badge ではなく ExperimentalBadge として提供されています。 次に、サンプルのプロジェクトを用意して webpack-dev-server でローカルサーバを用意します。 $ yarn init $ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin webpack-dev-server でローカルサーバが見れる状態になるように webpack.config.js に設定を記述します。 const path = require ( "path" ); const HtmlWwebpackPlugin = require ( "html-webpack-plugin" ); module . exports = { mode: "development" , devServer: { https: true , }, entry: { app: [ "./src/js/app.js" ], }, output: { path: path . resolve ( __dirname , "./dist" ), }, plugins: [ new HtmlWwebpackPlugin ({ template: "src/index.html" , }), ], }; 次に manifest.json を用意します。manifest.json は、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。 https://app-manifest.firebaseapp.com/ のようなサービスで manifest.json とアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。 {   "name" : "badging-api-playground" ,   "short_name" : "badge" ,   "theme_color" : "#5B5CFD" ,   "background_color" : "#5B5CFD" ,   "display" : "standalone" ,   "orientation" : "portrait" ,   "prefer_related_applications" : false ,   "Scope" : "/" ,   "start_url" : "/" ,   "icons" : [     {       "src" : "images/icons/icon-72x72.png" ,       "sizes" : "72x72" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-96x96.png" ,       "sizes" : "96x96" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-128x128.png" ,       "sizes" : "128x128" ,       "type" : "image/png"     },     {       "src" : "images/icons/icon-144x144.png" ,       "sizes" : "144x144" ,       "type" : "image/png"     },     ….   ],   "splash_pages" : null } webpack.config.js の方に manifest.json をローカルサーバで配信されるように設定を追加しておきます。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') + const CopyPlugin = require('copy-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new CopyPlugin([ +       { +         from: 'src/manifest.json', +         to: '', +       }, +       { +         from: 'src/images/icons', +         to: 'images/icons/' +       }, +     ]),   ], } ここまでで Chrome の Application タブから manifest.json が認識されいてることが確認できますが、インストール可能な状態にはなっていません。 アプリをインストール可能な状態にするには いくつかの基準 があり、service worker が必要になります。今回は Workbox の webpack プラグインで対応します。 yarn add --dev workbox-webpack-plugin workbox には GenerateSW と injectManifest の 2 つのモードがあり、今回はどちらでも問題ないかと思いますが injectManifest モードを利用します。 const path = require('path') const HtmlWwebpackPlugin = require('html-webpack-plugin') const CopyPlugin = require('copy-webpack-plugin') + const { InjectManifest } = require('workbox-webpack-plugin') module.exports = {   ….   plugins: [     …. +     new InjectManifest({ +       swSrc: path.resolve(__dirname, 'src/sw.js'), +     }),   ], } app.js の方で service worker の登録がされるように記述しておきます。 if ( "serviceWorker" in navigator ) { window . addEventListener ( "load" , () => { navigator . serviceWorker . register ( "./sw.js" ) . then (( res ) => { console . log ( res ); }) . catch (( err ) => { console . error ( err ); }); }); } service worker の対応が済むとインストール可能なアプリの基準を満たすので、Chrome76 ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。 インストールすると Launchpad にアプリアイコンが表示されたので、実際に Badge API を試してみます。 window.ExperimentalBadge.set() を呼び出すと、フラグとしてバッジがつきます。 window.ExperimentalBadge.set(1) のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。 window.ExperimentalBadge.clear() でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。 非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。 なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。 まとめ 近い将来正式リリースされる可能性が高い API を試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。 API 自体が Origin Trial の段階で、ブラウザのタブの favicon 上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。 最終的にどのように課題が解決されていくか注目したいと思います。
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 https://www.medley.jp/jobs/ https://www.medley.jp/team/creator-story.html
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催) 日程;7/30(火) - 8/1(木) 会場:東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト: Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子(背景と同色なのは偶然です) セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です! 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB(Cloud SQL)が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい) App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル(テーブル)の主な設定項目 FIELDS:モデルのフィールド情報を定義 DATASOURCES:データベースでいうところのビューに近い概念の設定 RELATIONS:モデル間のリレーションを定義 EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY:モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 :MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 (クライアントサイドからの操作限定)サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング :既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 :GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン :ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。( 文字列とアイコンの対応表 )一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない :Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します) ローカルの開発環境と上手く連携できない :Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない :Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。(RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています) GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社?気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp
みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社?気になった方はこちら https://www.medley.jp/team/
みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社?気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp