つばろぐ

福岡のエンジニアによる技術的な備忘録です。

Developers Summit Kyushu 2017で「クラウドやOSSで“デザイン”するモダンなシステムアーキテクチャ」という登壇を行いました

縁あって、今年のデブサミ九州にて登壇する機会を頂きました。
なぜかしら立ち見がでるくらい、多くの方に聞いて頂けてとても良い経験となりました。
ブログを書くまでがデブサミということで(?)。

event.shoeisha.jp

話したこと

開発者として、会社として、アプリケーションを作る上で意識している「アーキテクチャ」についてお話させて頂きました。

私が所属する株式会社オルターブースが提供している自社サービスで取り入れている考え方を例としています。

mysaucefactory.com

スライド

時間がなく割愛したスライドもAppendixとして載せてます。

これからやりたいこと

スライドで紹介しているキューイングによるSendGridでのメール送信という仕組みは、SendGridエバンジェリスト的にもアリな構成のようです。
デブサミ前日にお邪魔したSendGrid Night in Fukuoka #2にて近い話をしたところ、「SendGridでエラーになったらどうなるの?」というエラー検知に関する質問をもらいました。
Azure Functionsでエラーを知ることはできるけど、実際使うとしてどう振る舞うことができるのかは宿題として検証してみたいところ。

f:id:tech-tsubaki:20170922170231j:plain

博多Tech塾でレガシーからモダンにシフトする.NET開発手法について登壇しました

2017年8月19日に開催された「博多Tech塾」で登壇してきました。
きっかけは九州で活躍するフルスタックエンジニアのT-Katouさんにお声がけ頂いて、登壇することとなりました。

hakata-tech-juku.connpass.com

元々企画段階で、ASP.NETに関するセッションをしますよーと言ってましたがネタ作りに苦戦したので、もっと広げて.NET開発手法をどのようにしてレガシーからモダンにシフトするか、というテーマでセッションを行いました。

ただ、参加者への事前アンケートを教えてもらったら、みんなの興味はAzureだったみたいですw

スライド

登壇スライドはこちらになります。

テーマ

前職からの経験上、福岡のような地方都市の.NET開発現場はいまだにレガシーな環境が多く存在します。
そういった方がこれから.NET開発を続けていく中で、どう新しい手法や分野にシフトできるかなーと思って作りました。

ざっくり内容

  1. 開発環境編
  2. アプリケーション編
  3. フレームワーク
  4. コーディング編

これら4つの観点をそれぞれ取り上げて、現時点での新しい手法について紹介しました。

サンプル

セッションでは、ASP.NET CoreとDockerのデモや、LINQのデモを行いました。
LINQのデモで使ったコードはサンプルとして公開していますので、気になる方はどうぞ。

github.com

感想

今回の勉強会はMicrosoftの様々なテクノロジーを取り上げました。
初めましての方がほとんどで新鮮な気持ちになりましたが、全体的にセミナーっぽい雰囲気になってしまい、あまり交流することができなかったのが心残りです。

今日の参加者の中から、Fukuoka.NETにも興味をもってくれる方がいればいいなーという気持ちです。

キューをトリガーにしてSendGridでメールを送るAzure Functionsを作ってみた

SendGridを使って定形メールを送る場合、もうこの方法でいいんじゃないかと思ってきました。
メールサーバは自前で構築すべきでないし、現状はSendGridを使うことがベターだと思います。

とはいえSDKを使ってメール送信機能を自分で作るのすら面倒に感じていたので、Azure FunctionsのSendGridバインドを試してみました。

結論

いきなりコードを書くな。FunctionsポータルのGUIで作った関数をコード化しろ。

いきなりコードを書くな

このドキュメントにあるサンプルに従って、SendGridのメールを送る関数を作ってみたがうまく動かず。

docs.microsoft.com

Visual Studio 2015 + Tools for Azure Functionsで作ってたが、どうにもデバッグが面倒くさい。

Functionsポータルで関数を作る

このドキュメントに従ってポチポチとポータルで関数を作ります。すごく簡単。

docs.microsoft.com

いきなりQueueをトリガー(入力)にせず、ManualTriggerで「SendGridバインドでメールが送信できる」ことを確認すると分かりやすいです。
その後、トリガーをQueueに変更しましょう。

ストレージアカウントの接続情報やSendGridのAPIキーを直接コード上に定義するとコミット上から丸見えになってしまうので、App Serviceのアプリケーション設定に定義して、function.jsonから参照することで安全に管理できます。

f:id:tech-tsubaki:20170815003121j:plain

f:id:tech-tsubaki:20170815003419j:plain

SendGridのバインド設定はAPIキーのほか、以下の情報を設定にもつことができます。

  • APIキー
  • 宛先アドレス(to)
  • 差出人アドレス(from)
  • 件名(subject)
  • 本文(body)

コード化する

「Queueをトリガーにする」「SendGridでメールを送信する」という動作が確認できたら、それをコード化しましょう。
といってもFunctionsポータルで参照できる function.jsonrun.csx をコピペすれば良いです。
試しに作ってみたので気になる方は見てみてください。

github.com

このサンプルではQueueに送信先メールアドレスを入力することで、自動的にそのメールアドレスに対してSendGridからメールを送信する関数になってます。