by ·0件のコメント

2017/4/21のGlobal Azure Bootcamp 2018@Tokyoでお話してきました。

発表に使用したスライドはこちらです。

テーマ選定

スタンプカードアプリ作りたかった

妻が筋トレ（？）か何かをするにあたり、スタンプカードアプリ（別にアプリである必要はなかった）がほしい、スタンプはできれば猫がいい、みたいなことを言ってたのがきっかけの1つです。

※継続的に筋トレする習慣を作るのに必要なのは本当にスタンプカードなのかどうかはわからない

Durable FunctionのHuman Interactionパターン実装したかった

去年のServerless ConfかなにかでAzure Functionsの拡張機能であるDurable Fuctionsを知り、興味を持ちました。

中でもパターン #5: 人による操作に謎のロマンを感じ実装してみたくなりました。

一定以上のまとまりがあるコードが書きたかった

LTなり、何か記事を書くなり、技術系のアウトプットをするには技術的なインプットが必要と思っていますが、インプットの質を上げるためにももうちょっとアウトプットせねばという思いがありました。

しょうもなくてもいいからGitHubにひとまとまりのソースコードを上げられるだけコードを書くというのが今年の方針です。

振り返り

スライドでは主にコードについて書いてますが、もうちょっと取り組み全体寄りの振り返りです。

Good

  • クライアントもサーバもコードを書いてGitHubに上げたこと
  • 期待した動作をするアプリができたこと
  • Azure FunctionはHTTP Triggerを1回触る程度でよくわかってなかったけど、全体的なお作法をざっと見た上でDurable Fucntionsのキャッチアップに入れたこと
  • Durable Fucntionsの実行の仕組みもなんとなく把握できる程度にデバッグ実行したりストレージの中身のぞいたり研究できたこと
  • PaaSの組み合わせ方にもデザインパターンがあり、実装するからこそそのありがたみを感じられることを実感できたこと

Challenge

  • 声出すの、歌とかでなくてもほんとに音にならなくてつらい
  • 全部喋らんけど資料になるから資料厚くしよう、そして喋るときはいろいろ飛ばそう、はまだ自分には早そう
    • （練習した後）ギリギリまで資料を変えて本番に臨むとわりと混乱して大事などころだけ絞って喋るって緊張してると難しい。今回は資料アップロードした後もここ表現こうした方がいいとか、順番はやっぱこういう方がいいとか10回くらい直してアップロードし直した
  • 実装的にあれも足りないこれも足りないとウジウジしてないで学びたいことを学ぶためのサンプルと割り切ること
    • 足りないと思う部分はissueとかで残しとくともっと深めようとか現実的に稼働させたいとか思ったときに役立つかも
  • 一方で個人的に本番運用するプロダクトがあってもよいなぁ
    • クラウドリソースの認証・認可さすがにザルすぎる
  • ログの追い方は「とりあえずサンプル1つ動いた」の次の段階くらいで意識的に時間とって把握するのがよさそう
    • 今回くらいの規模のサンプルでも途中デプロイすることがあったり、単にブレークポイントはる以外にログきちんと追いたい局面が多々あった
  • Azure FunctionsがV1ベース
    • V2でやろうとするとnugetからのインストールからうまくいかなくて、古めのバージョンでうまくいく組みわせでやり過ごしてしまった感
  • 実行の仕組みの研究とか言うわりに「どう実装されているか」をコード見ながら考えてない。動きからテキトー想像する「だけ」は研究とは言わない
  • UI苦手やぁ
    • よくあるアプリのパーツ実装してみるとか、作りたいと思ってるものに沿った形で取り入れてみるのはやった方が表現の幅が広がっていきそう

まとめ

総じて取り組んでよかったなぁと思います。

需要があるかはおいておいて、今回のスライドでも20分くらいじっくり喋りたかった内容だったりするので機会があればリベンジしたいなぁと思いました。

あと、今回みたいなアーキテクチャでデータの整合性はどうすると保てるのかだったり、クラウドアーキテクチャの原則は何なのかだったり、もっと踏み込んで学んだら楽しそうな分野に出会えてよかったです。

クラス設計もデザインパターンからでなく、その前提となる原則やそれを実現するための具体的なコード（の変化）を追うととても実感がわきました。

今ではクラウド設計の原則的なことも整理が進んでいると思うので、追ってけたらなぁと思いました。

勉強会ではこのセッションが特に印象的でした。

by ·0件のコメント

10/1に Microsoft MVP を受賞しました。カテゴリは Visual Studio and Development Technologies です。

Microsoft 関連のテクノロジーを使用した開発を行う上で各コミュニティの先輩方の助けがあってなんとかなった部分は数え切れません。

感謝するとともに、自分もより多くの人の役に立てるようにいっそうがんばります。

以下、自分とコミュニティの関わりについて書きます。

MS MVP が何か、どういうメリットがあるか等については何も触れていないので、そういう情報が必要な方は公式サイトをご覧ください。

C# との出会い

僕は「エンジニア」という職業に憧れ、2015年1月に SIer 営業から転「職」しました。

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

最初の7ヶ月くらいは大体 Ruby を書いて（※書けない）過ごしましたが、2015年7月頃突然 Windows デスクトップアプリのプロジェクトにアサインされました。

それが C# や Visual Studio との出会いです。

まぁ何もわからなかったです。

前職で C# で書いていた UXデザイナーさんに Visual Studio の使い方を教えてもらったのは今となってはよい思い出です。

レビュー以外は基本的に自分しか触らない、ということは自分が開発を進められなかったらこの機能は世に出ない…！というプレッシャーがすごかったです。

（会社の中でわからないことを聞いても教えてくれる人はいたのかもしれませんが、）そのタイミングで利用し始めたのが teratail （もちろん Stack Overflow とかも）だったりします。

@Tak1wa さんを始めたくさんの方にすごいスピードで助けていただきました。

その助けがなければリリースまでたどり着かなかったかもしれない機能もたくさんあります。

感謝してもしきれません。

ここからオンライン・オフラインでの「コミュニティ」との関わりが始まりました。

はじめての Qiita

助けてもらってばかりの日々が続きましたが、無事大きな機能もリリースにこぎつけ、今度は自分も何か書いてみよう！と思っていると、世間は Qiita の（ Qiita をはじめとする？） Advent Calendar で賑わっていました。2015年の12月のことです。

はじめての Qiita 記事は C# の Advent Calendar です。

Windowsアプリで出たバグをBugsnagで管理し、Trelloでタスク化し、slackに通知する

C# との闘争

2016年になり、Windows アプリのメンテや機能拡張が半稼働、Ruby で書くのが半稼働という日々が続きました。

正直頭切り替えるのしんどいし、どっちも中途半端だし、C# での開発は社内でメインストリームではない…ということでだいぶモヤモヤしていました。

しかし、紆余曲折を経て、腰を据えて C# を勉強することに決めました。

2016年の5、6月には C# の基本書を改めて読み、 Qiita 記事も色々と書き始めます。

設計もできるようになりたいという思いで、『Java言語で学ぶデザインパターン入門』を C# で書き直すという Qiita 記事も書き始めました。

C#で学ぶデザインパターン入門 ①Iterator

はじめての .NET 関連勉強会

そういう言えば C# なり .NET なり勉強会行ったことないよな…と思い、行ってみることにしました。

近々開催予定だったのが .NET Fringe Japan 2016です。（2016/10/1）

Ruby や JavaScript の勉強会と雰囲気（いる人の層？）が全然違うし、何より何言ってるかさっぱりわからなかった気がします。

今思えば最初に行く勉強会としては誤りだったと思う一方、メンバーの濃い本当に貴重な勉強会だったと思います。

はじめての Xamarin

C# でモバイルアプリの開発ができるとか何とか？という話を聞き、へ〜って思っていると、Xamarin Dev Days Tokyo というイベントがあるというのを知りました。

世界中で Xamarin のハンズオンイベントをやるとのことで、参加してみることにしました。

環境構築が全然進まず困っていたところ、@_shunsuke_kawaiさんや @atsushienoさんに助けていただきました。

atsushieno さんが Xamarin の中の人だということは後から知りました。

Japan Xamarin User Groupという日本の Xamarin ユーザグループもあり、勉強会もほぼ毎月行なっているということを知りました。

その年の会社 Advent Calendar では C# というかなんというかな話を書きました。

技術的マイノリティプロジェクトで幸せに過ごすための5つの方法

年が明けるともっと Xamarin のことを知りたいと思い、 Xamarin.Forms 本の邦訳読書会にも参加し始めました。

XamarinFormsBookReading

そして自分でも Xamarin.Forms を使って簡単なアプリを作り始めました。（2017年4月）

Xamarin.Formsで家の日用品管理アプリを作り始めたお話

はじめての機械学習

Xamarin に触れる一方で、社内では機械学習の勉強会に参加していました。

Coursera の機械学習を見つつ、その演習問題をやってみたり、Kaggle の問題を解いてみたり。

その文脈で Azure Machine Learning に出会い、そのわかりやすさに感動してこの本をベースに社内でハンズオンをやってみました。（2017年4月）

インサイド Xamarin

会社でも Xamarin で開発をすることが決まり、de:code にも参加して Xamarin の話を聞くぞ！予習するぞ！というときにある連載に出会いました。

インサイドXamarin

Xamarin に限らず、ビルドとかコンパイルって何することなんやろう？そもそも .NET って何？みたいなことがとても気になり始めていた時期（遅）で、衝撃的に面白かったです。

理解できてない部分は多いとは思いますが、詳しく知りたい気持ちが増す大きなきっかけになりました。

はじめての LT

思うところがあり、2017年6月から LT をし始めました。

その経緯はこの記事に詳しく書いています。

Tokyo Jazug Nightで「Azure FunctionsとAWS Lambdaの開発フローの違い」を話してきました。初めての登壇とその理由 #jazug

はじめての LT は日本の Azure のユーザグループである JAZUG で行いました。

これからもっと Azure を使って行く予定なので、もっともっと実践的な知見を共有できたらと思います。

Microsoft MVP

その後もイベントでの登壇やサポートをしたり、業務関連の Xamarin 記事を書いたり翻訳したり、たまにコードを GitHub に上げたりしていました。

その結果、2017年8月までの1年間の活動を評価していただき、Microsoft MVP を受賞しました。

自分のエンジニアとしてのキャリアと Microsoft 関連技術は密に結びついており、とても嬉しくて受賞した日はほとんど眠れませんでした。

（訳あって9月以降の実績を含まずに受賞できたら嬉しいなぁ…と思っていたりもしました）

会社のチームに報告したり、全社集会で報告したり、察して祝っていただいたり、全社集会で報告する日にMVP Kitが届き開封の儀を執り行ったり、自分のことのように喜んでくれる人がいたりで徐々に実感も湧いてきました。

ただ、評価指標はあくまでコミュニティへの貢献で「エンジニアとしてどうか」ということではないと思っています。

今後、MVP を受賞したことで得られる機会を最大限活用し、これまでお世話になった方々のように多くの人が一歩踏み出す力になれるよう努力し、エンジニアとしてより大きな問題を解決できるよういっそう精進していきます。

by ·0件のコメント

7/25の第7回 Tokyo Jazug NightのLTで登壇してきました。

JAZUG

Japan Azure User Group (通称JAZUG) は、Microsoft Azureを学び、楽しみ、活かす、日本のユーザーグループです。2010/8/26に結成したばかりのコミュニティです。ぜひ、一緒に作っていきましょう。 ちょっと興味がある＝ゆるふわな方 から 実ビジネスで使うんだよね な方まで歓迎。 職種はなんでもござれ。 ※プログラマ~企画者、デザイナ歓迎。ゆるふわなコミュニティとお考えください。

connpass JAZUG (Japan Azure User Group) ページより

発表した資料はこちらです。

VSTS、Slack、Microsoft FlowでASP.NET CoreアプリのCIをやってみる

第6回にも登壇したので、そのときと比べてどうだったか、今後どうしていくかについて書こうと思います。

Tokyo Jazug Nightで「Azure FunctionsとAWS Lambdaの開発フローの違い」を話してきました。初めての登壇とその理由 #jazug

このテーマにした理由

当初は「そんなに使わないけどたまにテストで使うASP.NET CoreアプリのCIとリソース管理（使うときだけ　SlackとかでさっとApp Service立ち上げるイメージ）」をうやるべく、VSTS使ったり、下に貼ったスライドのようにAzure Automationでよしなにしてくれる仕組みを作ろうと思っていました。

第６回の記事に書いたように、直面している問題の解決が第一にあって、副次的に発表ネタが増えるみたいな感じにしたかったんです。

しかし、そのASP.NET Coreアプリは別にローカルで立ち上がればそれでよいという話になって前提がなくなってしまいましたw

※問題が、問題解決のための労力を割かずして解決するのはよいことです

ただ、

  • VSTS触ったことなかった
  • CIツールそもそも触ったことなかった
  • CIツール以前にビルドフローで叩かれるコマンドってどんなのがあるのかよくわかってなかった
  • Logic Apps面白そうだった（けど触ったことなかった）

というのもあり、大枠のテーマは変えないことにしました。

前回の振り返りを踏まえて改善したこと

前回の振り返りはこうでした。

Good

  • LTに臨む指針ができた
  • 会社でMS関連の技術扱ってることをLT後も含めて伝えられた
  • 他社の方と一緒に何かをやるきっかけができようとしている

Challenge

  • 間違ってる部分があった
    • シーケンス図→会社の人に教えてもらった。修正済み。LTくらいなら先に会社でさっとやってしまうとよさそう
    • Azure Functionsの実行時間は5分から10分に伸びた→LTの準備段階で参考にさせていただいたブログ書いてらっしゃる方のLT資料に対するご指摘。ありがたい。完璧に準備するのは無理なので、指摘もらった点は資料に反映していくようにしよう
  • 緊張しすぎわろた→もうちょい練習しよう
  • 平日準備厳しい→土日に8割方終わらせても平日に残りやり切るの厳しいタイミングもあるので、平日は練習するだけ、練習時に気づいたこと直すくらいに…
  • 変換コネクタ貸してもらえなかったらアウトだった→type C to HDMIしか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

で、それを踏まえて変えた部分はこんな感じです。

改善点

間違ってる部分があった、緊張しすぎわろた

自分で何回か読む練習したのと、嫁氏がエンジニアなので変なところがないか聞いてもらいました。

嫁氏は今回発表した技術を普段使ってるわけではないことは棚に上げます。

平日準備厳しい

火曜日開催だったのでその前の土日には仕上げました。

変換コネクタ貸してもらえなかったらアウトだった

今回は（も）動画撮影の会社の方が準備してくださってましたが、購入したのでいつでも大丈夫！

UGREEN Type C USB アダプター VGA 3in1 USB3.1 C to VGA/ USB3.0/ USB-C PD MacBook Huawei Matebook Chromebook Pixel対応 Type C 変換 VGA

posted with カエレバ

その他

前回の内容はスライド見るだけではあまりにざっくりでだからなんやねんみたいな感じになってしまったので、今回は合わせてQiita記事にもしときました。

反響なさすぎて寂しいですが、備忘のため…（つよがり）

振り返りと今後

振り返り

Good

  • VSTS、Logic Apps、Microsoft Flowも触ったことなかったけど一応形になった
  • うまくいかないときフォーラムで聞いてみたら回避策が見つかった
  • 今回VSTS、次回MS Flowみたいな感じに分けようかと思ったけど、その時点で持ってる知識全部出して次はまた別のことやるべきって思ってそうしたこと

Challenge

  • 前進させたい
    • うまくいかないってtwitterで言ってるよりはフォーラムでも書くほうがマシではあったけど、OSSならPR出したり再現できる形でissue上げたり、英語で書いて開発してる人によりフィードバックが届きやすい形にすることで改善なり前進なりに繋がるようにしたい
  • 問題はより目の前のものを
    • 今回も調べ始めたらどんどん気になることが出てきて楽しかったけど、深堀っていく対象は選ばないと人生進捗しない感がすごい
  • 内容濃くない割りに詰め込みすぎで早口
      5分のLTに妥当な内容とはとか考えると悩みしかないけど、詳細は別にするにしても内容1つに絞ったほうがよいかも。けどまぁ人に行動促すんじゃなくて、自分が勉強するためにやってるしいっか…

今後

次は8月末の初心者歓迎XamarinのLT会！Xamarin入門者の集い #3でお話しします。

仕事でXamarin触っているので、強くなりながら臨めたらなぁと思います。

by ·0件のコメント

6/22の 第6回 Tokyo Jazug Night のLTで登壇してきました。

JAZUG

Japan Azure User Group (通称JAZUG) は、Microsoft Azureを学び、楽しみ、活かす、日本のユーザーグループです。2010/8/26に結成したばかりのコミュニティです。ぜひ、一緒に作っていきましょう。 ちょっと興味がある＝ゆるふわな方 から 実ビジネスで使うんだよね な方まで歓迎。 職種はなんでもござれ。 ※プログラマ~企画者、デザイナ歓迎。ゆるふわなコミュニティとお考えください。

発表した資料はこちらです。

connpass JAZUG (Japan Azure User Group) ページより

Azure FunctionsとAWS Lambdaの開発フローの違い

今回、社外・面識のない方が大半の場で登壇するのが初めてでした。そのため、なぜ登壇しようと思ったのか、これからどうしていくのかとかその辺書き残しておこうと思います。

登壇のきっかけ

マネジメント

色々あった気もしますが、根本にあったのは特に技術面での成長に対する不安だったと思います。

営業から業務プログラミングとか0でエンジニアへ転職したのが2015年の1月。

思うように伸びない時期が大半だった気もしますが、2017年4月、正式にロールとしてチームの運営的な部分もやっていくことになり、拍車がかかったというのが大きかったと思います。

当時といってもそんなに時間経ってないですが、こんなことを考えていました。

  • マネジメントも様々な技術分野同様、専門知識のある一分野なのでキャッチアップしないと
  • 業務として純粋にコード書いたりする時間減るかも
  • 技術大してないのにマネジメントってなんというかダサい

マネジメントが技術的成長を妨げるとは全く思ってなくて、技術的に成長していける確認が持てていないタイミングでマネジメントもやる絶望感がただただありました。

インプットの質を高めるためのアウトプット

チームではMicrosoft関連の技術を扱っていて、品川でよく開催されている勉強会にけっこう頻繁に足を運んでいました。

3/25に参加したのがこちら。

.NETラボ 勉強会 2017年3月

.NETラボ 勉強会 2017年3月のまとめ #dotnetlab

後の懇親会で色々と話を伺っていると、雰囲気的に自分も登壇できたらなぁと思いました。

そしてたまたま当日目について記事がこちら。

“ただの興味”がいつか武器になる–及川卓也氏が語る、一流エンジニアのアウトプット法

インプットしないかぎりアウトプットできないので、最初にアウトプットするということを続けていくと、必然的にインプットしなければいけなくなるのです。

僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます（笑）。">僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます（笑）。

あと、デザインパターン勉強していて、けどなんかしっくり来なくて「どうやって勉強したらいいですか？」って聞くと、

「実際にデザインパターンが必要な必要な開発・シチュエーションに出会って適用すること！」

っていうお話をしていきました。これは登壇のきっかけではないのですが、自分の「技術的成長に対する不安感」の核心なので後でまた触れます。

今度はどこで話すかというお話です。雰囲気的に3月に参加した.NETラボさんでお話できたらなぁと思っていました。

が、毎月第四土曜に開催されるこの勉強会は参加できないことが多く、どうしよう、と…

思っていたときに4/22のGlobal Azure Bootcamp 2017@Tokyoに参加してやっていく気持ちが高まり、5/17のJAZUG女子部 第11回勉強会で今回登壇した第6回 Tokyo Jazug NightにLT枠があると知って（？）20秒くらい悩んで申し込んでみました。

ネタはまだない。

話すネタ

そう、申し込んでみたものの何も決まってない。

そもそも5分のLTってどういうのあるんやろう…

  • 最新情報・動向
  • 新しい技術試してみた
  • 導入したときのtips
  • Deep Dive
  • 俺の作ったサービスを見てくれ
  • なんとなくエモい話

とかとか？形から入ると一番大事な部分、話す内容がない。

折しも社内ではピアレビューというのがある時期。

会社では定期的にマネージャー以外にも近くで仕事をする同僚から良い面と良い面を伸ばすために必要なことを書いてもらう機会があります。

そこでもらったコメントの一部がこうでした。

  • 得意分野ができて技術をインプットするサイクルはうまく作れるようになったと思うので、今度は情報をまとめるだけじゃなくアウトプットを意識するといいと思う。ここで言うアウトプットは社外での発表とかそういうものではなく、ちゃんと技術を形にしたものであるべき。
  • Webアプリ開発などの基礎的なスキルはまだまだ不足していると感じるので、引き続きエンジニアとしてのレベルをトータルで1段あげれるような取り組みはしていったほうがいいと思う。これも勉強会に参加するとかじゃなくて手を動かす時間を取ったほうがいい。

まさに自分が直面している問題の話でそうだなぁと思う一方で、もっと意図が知りたいと思ったのでランチのお時間いただきました。

誤解を恐れつつまとめると

「自分が困った問題の原因を考え抜く、調べきる」

です。

そういうわけで、LTするにしても、LTのためのネタ集めをするのではなく、問題に向き合うことを大前提にすると決めました。

その課題を解決する手段として、今回であればAzure技術を位置付けるような形で話できるのが理想であると。

先ほども少し触れたように「デザインパターンどう勉強したらいいですか」みたいな質問をしてしまう前提として、漠然と自分の打ち手がないことへの不安から何となく教科書的なものを一通りさらっていくような勉強してしまうという自分の弱点があります。

体系的な知識が必要な場面はあるとは思うものの、自分に圧倒的に足りてなかったのは問題そのものに向き合う姿勢でした。

サーバレスアーキテクチャ

今回LTで話したのはAWS Lambdaの話とAzure Functionsの話です。

サーバレスアーキテクチャとか、話は最近よく聞くし、ポップでキャッチーな響きなので登壇後も優しい方々がいいねやリツイートしてくださいました。

もちろん、このLTの準備はサーバレスアーキテクチャに始まっていなくて、メインは

こうだったのが

こうなった

というのが中核です。

アプリへのレスポンスを改善するためにとった手段が最終的にサーバレスアーキテクチャになっただけで、beforeとafterの間に移行のための別アーキテクチャがあったりします。

とはいえ、手段としてのAWS　Lambdaの特性を知るためのAzure Functionsの勉強はとても有益でした。

  • 「サーバレスアーキテクチャ」としてメリット・デメリット
  • 制限事項への対応
  • 新機能の意図

は特定のプラットフォームにだけ活きるものではなく、両者に活きるものだからです。

LTのスライドだけ見ると、ちょろっと調べれば何となくまとめられてしまいそうな内容になっています。しかし、最終的な成果物がどういう形であれ、問題に向き合うプロセスは別に形にしたり、こんな風に書き留めておきたいと思っています。

登壇の振り返り

そういうわけで、7/25実施の第7回 Tokyo Jazug NightにLT枠で既に申し込んでいます。

よりよくしていくためにほんのちょっと振り返ります

Good

  • LTに臨む指針ができた
  • 会社でMS関連の技術扱ってることをLT後も含めて伝えられた
  • 他社の方と一緒に何かをやるきっかけができようとしている

Challenge

  • 間違ってる部分があった
    • シーケンス図→会社の人に教えてもらった。修正済み。LTくらいなら先に会社でさっとやってしまうとよさそう
    • Azure Functionsの実行時間は5分から10分に伸びた→LTの準備段階で参考にさせていただいたブログ書いてらっしゃる方のLT資料に対するご指摘。ありがたい。完璧に準備するのは無理なので、指摘もらった点は資料に反映していくようにしよう
  • 緊張しすぎわろた→もうちょい練習しよう
  • 平日準備厳しい→土日に8割方終わらせても平日に残りやり切るの厳しいタイミングもあるので、平日は練習するだけ、練習時に気づいたこと直すくらいに…
  • 変換コネクタ貸してもらえなかったらアウトだった→type C to HDMIしか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

次回もがんばるぞー

スライドにも書きましたが、この本よかったです。今AWS Lambda始めるならこれ！という感じです。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

posted with ヨメレバ
西谷 圭介 マイナビ出版 2017-06-09