最近聞いてる技術系ポッドキャストまとめ

f:id:Keisuke69:20200625161245j:plain

はじめに

コロナの関係でいろんな生活習慣が変わってきています。僕の中でも変わったことがいくつかあってその一つがポッドキャストです。

これまでポッドキャストというのはほとんど聴くことがありませんでした。

特に理由はなかったのですが習慣がほとんどなかったんです。過去に少し聞いたときもあったのですがそれほど面白いコンテンツとも感じませんでした。

ところが、最近Twitterのタイムラインでfukanori.fmをよく見かけたので試しに聞いてみてとても面白かったんですね。それがきっかけでいろいろ聞くようになりました。

というわけで僕がよく聞くポッドキャストをいくつかあげていきます。仕事がら技術系のポッドキャストが多いです。なお、都合によりリンクはAppleポッドキャストだけですが、おそらくGoogleSpotifyでも配信されていると思います。

ちなみに現状では主にランニングしながら聞いてることが多いですね。まさにコロナ需要。

よく聞くポッドキャスト

主に新エピソードが配信されたら必ず聞くポッドキャストたちです。

fukabori.fm

podcasts.apple.com

冒頭でも書いたとおり、今のようにポッドキャストを聞くきっかけとなったポッドキャストです。

Iwashiさんが有識者や著名人を招いて番組名どおり深堀りしていくポッドキャストです。この聞く、質問するに徹する感じがインタビュー力の高さを感じさせるとともにこういうスタイルもありなのかと思った。

内容的にもソフトウェア開発に限らず、k8sとか開発プロセス、デザインや採用までと幅広いです。新しいエピソードを楽しみにしている1つです。

UIT INSIDE

podcasts.apple.com

LINEのフロントエンド周りの開発をしているUIT室の開発者によるポッドキャスト。フロントエンド、特にJS関連の話が多いです。

たまにミートアップも開催されています。これもまた更新を楽しみにしているものの1つで昨今における僕のフロントエンド周りの知識はここできっかけを仕入れていることも多いです。

Software Engineering Daily

Software Engineering Daily

Software Engineering Daily

  • Software Engineering Daily
  • 技術ニュース
  • ¥0
podcasts.apple.com

これは英語のポッドキャストですね。なんと毎日更新。おすすめのポッドキャストを探しているときにTwitterで教えてもらったものです。

fukabori.fm同様にいろんな人をゲストに招くインタビュー形式です。

ソフトウェア・エンジニアリングと言いつつも内容的にはKubernetesから各種OSSや各企業の開発組織の話など範囲は広いです。あと機械学習関連の話題も多め。

米国発なだけあってゲストもUberFacebookといった日本ではあまり話を聞く機会がない会社のエンジニアが多いのも特徴です。

あと、英語とは言え非常に聞き取りやすいです。

mozaic.fm

podcasts.apple.com

Jxckさんが月一回くらいの頻度で提供しているポッドキャストです。長めです。

内容はWeb標準や次世代Web周りが中心です。その月にあったブラウザ周りのアップデートなどをかなりのボリュームで紹介してくれるのでWeb界隈の最先端をざーっと知るのにとてもいいです。

これも大好き。

ポッドキャスト | Serverless NOW

podcasts.apple.com

Serverlessを愛する2人が届けるポッドキャストです。今の所不定期だと思います。

Serverlessを愛する者の1人として聞き逃すわけにはいきません。僕も過去にゲスト出演しました。

たまに聞くポッドキャスト

ここからはエピソード更新のたびに聞くというより、興味のあるエピソードだったら聞くといったものです。

Behind The Tech with Kevin Scott

podcasts.apple.com

MicrosoftのCTOであるKevin Scottがやってるポッドキャストです。MicrosoftのCTOだからといってMicrosoftテクノロジーだけを扱っているわけではなく、むしろMicrosoftテクノロジーには直接関係のない広範な話題を扱っています。

こちらもゲストを招いていることが多いです。英語です。

Code[ish] JP

podcasts.apple.com

日本のHerokuの人によるポッドキャストです。ゲストを迎えて月に一回くらいの頻度で更新されています。ソフトウェア開発そのものの話題よりもその周辺を取り巻く環境などの話題のほうが多めだと思います。

Rebuild

Rebuild

Rebuild

podcasts.apple.com

日本の誇るソフトウェア開発者の1人である宮川さんがやってるポッドキャストです。最も有名な技術系ポッドキャストと言っても過言ではないかも知れない。

基本的にゲストを迎えての雑談系です。

しがないラジオ

しがないラジオ

しがないラジオ

podcasts.apple.com

ゲストを招いて複数人でやってることが多いです。ソフトウェア開発そのものというより、開発組織やキャリアに関する話題が多めです。

engineer meeting podcast

engineer meeting podcast

engineer meeting podcast

podcasts.apple.com

おそらく若手のエンジニア数名による雑談系ポッドキャストです。

omoiyari.fm

podcasts.apple.com

Scrum開発やアジャイルに関する話題を中心としたポッドキャストです。ゲストを招いていることも多いです。

各社のアジャイル開発への取り組みなんかを聞けることが多いです。

アジャイルラジオ

podcasts.apple.com

こちらもアジャイル開発に関する話がメインのポッドキャストです。アジャイルにまつわる様々なトピックをテーマに数人で語るスタイルです。

ポッドキャスト始めました

というわけで僕が最近聞いているポッドキャストをざっと紹介したのですが、聞いているうちに自分でもやりたくなって、同僚の@toriclsと2人で始めました。特にテーマも定まっていない技術系ポッドキャストですがよかったら登録してください。

podcasts.apple.com

一応、GoogleSpotifyにも登録されています。

今の所は自分たち2人で話したものだけですが、ぼちぼちゲストを呼びつつ技術的ないろんな話を聞きたいと思っています。クラウドとかAWSの話題が中心というわけではなく、雑多な話を扱っていきます。自分たちがあまり明るくない方面のゲストを呼んでディープに話を聞いていくこともやっていきたい。あとはフレームワークの開発者とかそういう人呼んでいろいろ話聞くとか。

なお、なるだけ省力でやっていきたいので今の所オープニングとかエンディングとかそんな小洒落たものはありません。いきなり始まって突然終わる感じです。省力すぎて名前も『名無しさんのポッドキャスト』のままでいくことになった。

そんな感じなのでアートワークも僕がとりあえずで作ったものです。そのうちちゃんとデザイナーに発注しようと思います。

Gridsomeで作ったサイトをせっかくなのでちゃんとホスティングしてみる、Amplify Consoleで。

f:id:Keisuke69:20200609112825p:plain

はじめに

先日、Gridsomeを試したわけですがせっかくなのでホスティングしてみようと思いついたため、サクッと試してみようと思ったらサクッとできたのでメモ。

www.keisuke69.net

ホスティングにはNetlifyあたりが鉄板かと思いつつ、ここはやはりAmplifyでしょーということでAmplify Consoleを使ってます。

なお、前回使ったAWS Lightsailをつかって立てたWordpressは削除してしまっていたので、そこは話題のShifter Headless使ってます。

www.getshifter.io

Shifter

サーバーレスなWordPressのサービスです。 StaticとHeadlessの2種類あって今回は後者のHeadlessを使います。

Free trialで7日間なら無料で使えますのでサクッとサインアップします。

前回同様、ここにはてなブログのデータをインポートしていきます。と思ったらインポーターが使えないようです。。。困ってたら、

と教えていただきました。もう一回、WordPress立てる必要あるのかーと思ってたらShifter StaticでもOKとのことだったのでそっちで。

手順は前回と同様の手順でShifter staticに一度インポートして、今度はWordPressの形式でエクスポート、それをHeadless側でインポートします。ちなみにShifter Staticって静的サイトジェネレータなのでWordPressの管理画面を触りたい場合はインスタンスを作業時のみ明示的に立ち上げる必要があります。

Shifter HeadlessへのインポートはAll-in-One WP Migrationというプラグインを有効にしておけばできます。

ところで、Shifterって初めて利用したんですが、Dashboardの各種値がクリックされると勝手にコピーされるのとても使い勝手がいいですね。また、初見で何も見ずにセットアップ可能なのも簡単でよかったです。

Gridsome

Gridsome側は基本的には前回のやつのURLをShifter Headlessで用意されたURLに変更するだけです。ただ、今回はPublic Repositoryに置くのでgridsome.config.jsにベタ書きするのではなく環境変数BASE_URLから取得する方法に変えています。もちろん環境変数は自分でセットする必要ありますよ。これはこのあとのAmplify Consoleでも必要です。

    {
      use: "@gridsome/source-wordpress",
      options: {
        baseUrl: process.env.BASE_URL, // required
        typeName: "blog",
        apiBase: 'wp-json',
        perPage: 10,
        concurrent: 1,
      },
    },

試しにgridsome developでしたところ特に問題もなくさくっと動きました。

Amplify Console

静的サイトのホスティングに今回はAmplify Consoleを使います。

aws.amazon.com

Amplify Consoleでは任意のリポジトリと結びつけることで更新があるとビルドして公開するってのが自動でできます。今回はGithubのPublic Repositoryとして作ってるのでそれと紐付けます。

ここからはAWSのマネージメントコンソールでやっちゃいます。

f:id:Keisuke69:20200612123104p:plain f:id:Keisuke69:20200612123125p:plain f:id:Keisuke69:20200612123150p:plain

基本的にデフォルトのままで大丈夫なのですがBuild Settingsだけ少し修正します。baseDirectoryをGridsomeでビルドした成果物の出力先である/distに変更するだけです。 f:id:Keisuke69:20200612123220p:plain f:id:Keisuke69:20200612123408p:plain

設定が終わると自動的にビルドからデプロイが走るのですが今回は先の環境変数をまだ設定していないので最初の一回は失敗します。 f:id:Keisuke69:20200612123430p:plain

環境変数を設定します。 f:id:Keisuke69:20200612124155p:plain

右上のRedeploy this versionを押して再度デプロイします。 f:id:Keisuke69:20200612124411p:plain

今度は成功。 f:id:Keisuke69:20200612124511p:plain

というわけで表示されてるURLにアクセスすると無事にデプロイされてることがわかると思いますー。同じデータでやったので表示内容は前回と一緒です。 f:id:Keisuke69:20200612124839p:plain

簡単ですね。ブログ書くほうが時間かかるってくらい簡単。

ここらへんが気になる

今回、Amplify Consoleでデプロイをしてみたわけですが、こういったGitでのフローの場合にいくつか気になったのがコンテンツ更新からサイト更新の運用フロー。

静的サイトジェネレータなので新しい投稿をしたらビルドし直す必要があるんですが、それってどういうフローでやるのがベストなのか気になります。

コンテンツを更新したらローカルでビルドして/distの下だけホスティングサイトにアップするって運用が多いんですかね?コンテンツを更新する人って必ずしもエンジニアではないと思うのですがそのあたり実運用ではどうやってるのか気になりますね。

プロダクションでこの手のサイトを運用している人はこのあたりどうしてるのかな。

新たにPodcastを始めました。名前はまだない

最近、Tech系のPodcastを聞くことが増えていて聞いてるうちに自分もやりたいなーと思っていたPodcast@toriclsに全面的におんぶに抱っこな感じで始めました。

こちらで聞けます。なお、割と僕はダラッとした気怠い感じで喋りがちなので再生速度を1.25倍くらいにするといいと思います。

www.buzzsprout.com

前半は割と雑談ぽい感じで後半は先日ブログにも書いたGridsomeの話をしてます。

全般的に見切り発車感が強く、正式な名前も決まっていません。あとオープニングとかエンディングとかももちろんないし、ちゃんと考えずに喋ったため1.5時間も喋ったのにいろいろカットした結果、20分ちょっとになってしまった。

そのうち、ちゃんと名前とかサイトとかも作っていく所存。AppleとかSpotifyPodcastに載せるのが夢です。

話の内容としてはリンク先にNoteがありますが、カットされた話としては以下のような内容を話してました。

  • 社内事情、人材の話
  • 昨今のオンラインイベント事情
  • 各社ベンダーカンファレンスの話
  • 最近の個人的なソフトウェア開発事情
  • Kubernetesは本当に必要か
  • ソフトウェアエンジニアからみたk8sとかクラウド
  • Jeffyの話
  • OSSとかエコシステムの話

学んだことはふざけ半分のいじりとかすると編集が大変。編集したのは僕じゃないけど。

今後はこんな話とかしたり聞いたりしたいと勝手に思ってます。あとはその道の第一人者とか詳しい人呼んで一方的に話を聞く回とか。

日本発のサーバーレスアプリケーション開発向けフレームワーク『Jeffy』を試したので紹介する

f:id:Keisuke69:20200610221239p:plain

はじめに

サーバーレスアプリケーションの開発に使えるフレームワークはいくつかあるけれども、アプリケーションそのものにフォーカスしたフレームワークって実は少ないと思ってます。もちろん知らないだけって可能性も高いですが。

例えばServerless FrameworkやClaudia.js、AWSの提供するServerless Application Modelなんかはアプリケーションフレームワークというよりも、サーバーレスアプリケーションの管理とデプロイのためのツールだと個人的には捉えています。

また、AWSが提供するものとしてChaliceというPython製のフレームワークがありましてこれはPythonAWS Lambdaを使ったサーバーレスアプリケーションを開発するにあたって、Pythonで書いたコードに対してデコレータを指定していくことでリソース定義も同時に行われるという感じでして、いわゆるアプリケーションフレームワーク的に開発ができるので好きだったりします。

そんな中で日本の誇るサーバーレスフルコミットデベロッパーである堀家氏(@horike37)率いるServerless OperationsがJeffyというPython向けのアプリケーションフレームワークをリリースしたということで期待を込めて早速見ていきつつ簡単に紹介したいと思います。

github.com

期せずして今回もPython向けとなってはいます。ちなみに以前、個人的にTwitter上で2回ほどアンケート調査をしたのですがどちらも圧倒的にPythonが多かったです。Twitterなので多少のバイアスがかかっているとは思うものの体感としてもPythonが多い気がしています。一方で海外勢はNode.jsを使うことが多いって話を聞いたこともありますね。

一回目

二回目

Jeffy

Pythonでサーバーレスアプリケーションを開発するためのフレームワークです。サイトを見たところ以下のポイントにフォーカスして開発してるとのこと。

  • Logging: 全てのデコレータは全イベント/レスポンス/エラーを補足してJSONフォーマットで簡単に見れるように。独自の属性も追加することも可
  • Decorators: AWS Lambdaを使う上で毎回のように必要となる実装をPythonのデコレータで省力化
  • Tracing: correlation_idを受け渡しすることで関連するLambda関数とAWSサービス内でイベントをトレース
  • Configurable: You can customize the framework settings easily.

Lambdaでアプリケーションを開発する場合、Lambda関数という言葉の通り1つ1つの関数はできるだけシンプルかつ単機能なものとして実装して複数の関数やAWSサービスなどを協調動作させていくわけですが、それがゆえに複雑になりがちな不具合調査とか、頻発する処理の抽象化あたりにフォーカスしている模様。

ちなみにざっと見た感じ開発に特化しているためか、デプロイ周りの機能はなさそう。なのでLambda関数なり連携するAWSサービスなりのリソースは別の手段で自分で作る必要がありそうです。今回はServerless Frameworkを使ってやってしまいます。

あと、CLIで対話的にコマンド実行することで雛形となるプロジェクトであったりそういったものが自動で作成される、といったものでもないです。

インストール

普通にpipなどでinstall可能です。僕はPoetryを使っているので以下のような感じでインストール。

$ poetry add jeffy

事前準備

前述のとおりJeffy自体にはリソースを作成したりデプロイしたりといった機能はないので、試すためのリソースを事前に用意しておきます。今回はServerless Frameworkを利用してやっていきたいと思います。

Serverless Frameworkの導入とか初期セットアップは割愛しますが、初めての人はこちらのQiitaの記事を参考にするといいかもです。ちなみにこれも@horike37氏の記事です。

qiita.com

とりあえず今回はこんな感じで作成しています。

$ serverless create --template aws-python3 --name jeffy-sample --path ./jeffy-sample

本来であればserverless.yamlに作成する関数などの設定をしていくのですが今回はデフォルトのままでとりあえず行きます。デフォルトだとリージョンがus-east-1になってしまうので東京リージョン使いたい人は以下のように指定するといいです。

$ cd jeffy-sample/
$ serverless deploy --region ap-northeast-1

マネージメントコンソール上でLambdaのコンソールを確認するとjeffy-sample-dev-helloというLambda関数が作成されていることが確認できると思います。

実行してみます。

$ serverless invoke --function hello --region ap-northeast-1
{
    "statusCode": 200,
    "body"
}

はい、というわけで基本的なものが作成できたのでここからはこの関数に対してJeffyを使ってごにょごにょ試していきたいと思います。

Serverless Frameworkで作成されたhandler.pyにまずはちょっと追加してみたいと思います。

追加するのはログ周りの基本的な処理です。

import json
from jeffy.framework import get_app

app = get_app()

def hello(event, context):
    body = {
        "message": "Go Serverless v1.0! Your function executed successfully!",
        "input": event
    }

    response = {
        "statusCode": 200,
        "body": json.dumps(body)
    }

    app.logger.info({'foo': 'bar'})
    
    return response

    # Use this code if you don't use the http event with the LAMBDA-PROXY
    # integration
    """
    return {
        "message": "Go Serverless v1.0! Your function executed successfully!",
        "event": event
    }
    """

app.logger.infoで任意のログメッセージを出力できます。

早速これをデプロイするわけですが、今回のように依存するライブラリがある場合、それらをデプロイパッケージとしてまとめる必要があります。serverless deployそのままではデプロイできないのでそのあたりをよろしくやってくれるプラグインであるserverless-python-requirementsを利用します。

しかも僕の環境はPoetryなのでrequirements.txtを手動で出力してから実行とか必要かなと思ってたんですが、なんとこのプラグインはそれを自動でやってくれるんです。ありがてぇ。

$ sls plugin install -n serverless-python-requirements

serverless.yamlプラグインの設定を追加。

plugins:
  - serverless-python-requirements

インストールできたらserverless deployでデプロイした後、実行してみます。ちなみに実行はserverless invoke --function <ファンクション名>でひとまずはOKです。このときも必要であれば--regionオプションで使いたいリージョンを指定できます。

というわけで実行結果なんですが以下のようなJSON形式のログがClouwdWatch Logsに出力されていることがわかります。ログって単純にprintで標準出力でも出せますが情報量が圧倒的に違いますね。

また、公式ドキュメントではPythonLoggerを使う方法を案内してますが、これもログレベル、タイムスタンプ、リクエスト IDが追加されるだけなのでやはり情報量が圧倒的に違うとも言えます。

{
    "name": "jeffy",
    "msg": {
        "foo": "bar"
    },
    "args": [],
    "levelname": "INFO",
    "levelno": 20,
    "pathname": "/var/task/handler.py",
    "filename": "handler.py",
    "module": "handler",
    "exc_info": null,
    "exc_text": null,
    "stack_info": null,
    "lineno": 17,
    "funcName": "hello",
    "created": "2020-06-09 11:21:29,206",
    "msecs": 206.1450481414795,
    "relativeCreated": 481.66751861572266,
    "thread": 140024725681984,
    "threadName": "MainThread",
    "processName": "MainProcess",
    "process": 7,
    "aws_region": "ap-northeast-1",
    "function_name": "jeffy-sample-dev-hello",
    "function_version": "$LATEST",
    "function_memory_size": "1024",
    "log_group_name": "/aws/lambda/jeffy-sample-dev-hello",
    "log_stream_name": "2020/06/09/[$LATEST]e48f95444f6746ce92e449231b3f38fa"
}

ちなみに、任意のメッセージはmsgの下に出力されます。今回はサンプル通りapp.logger.info({'foo': 'bar'})としているのでJSON形式でネストされた感じで出力されてますが、ここの引数の部分は単なる文字列でも大丈夫でした。

その他、こんな感じでログに出力する属性を追加したり、

app.logger.update_context({
   'username': 'user1',
   'email': 'user1@example.com'
})

ログレベルを変更することもできるそう。

from jeffy.settings import Logging
app = get_app(logging=Logging(log_level=logging.DEBUG))

出力されている内容も公式のサンプルより多かったりするけど、このあたりは追えてないです。このあたりのログの出力内容を減らしたりすることはできるのだろうか。

デコレータ

個人的にいいなと思ったのがこのデコレータ。Lambdaでアプリケーション書くときに必ずやるような処理を簡単にしてくれます。サーバーレスでコード減ってるのをさらに減らしてくれます。例えば、エラーハンドリングであったりKinesisやSQSをイベントソースとして使う場合のレコードをパースする処理なんかをやってくれます。こういうボイラープレート的な処理をやってくれるのはよりビジネスロジックに集中できていいのではないでしょうか。そもそもデコレータとかアノテーションとかって仕組みが個人的には好きだったりします。

早速試してみます。なお、ここからは適宜Lambda関数自体をわけて試していきます。あとここからはserverless invoke localでローカル実行してます。

まずは共通系とも言えるエラーハンドリングを自動でやってくれるやつ。これは例外が発生したときにエラーの情報とともにイベントやレスポンスの情報も出力してくれるらしい。試すにあたってはとりあえずゼロ除算で試してみました。

だがしかし、つけただけでこける。なんだこれは何がいけないのか。 -> Issue切ったところすぐに直りました。試してた途中で見つけたもう1件もあわせて切ってこちらも対応済。速い!

というわけで気を取り直してやっていきます。

まずは何もつけないパターン。

import json
from jeffy.framework import get_app
app = get_app()

def handler(event, context):
    return 1/0

これを実行するとこんな出力になります。

Traceback (most recent call last):
  File "/usr/local/lib/node_modules/serverless/lib/plugins/aws/invokeLocal/invoke.py", line 86, in <module>

    result = handler(input['event'], context)
  File "./decorator_sample.py", line 7, in handler
    return 1/0
ZeroDivisionError: division by zero

ま、普通ですね。これに対して以下のようにhandlerに対してデコレータを設定して実行してみます。

@app.handlers.common()
def handler(event, context):

なお、ここではevent.jsonというイベントの情報を静的に定義したファイルを用意して、実行時に-p event.jsonをつけて実行しています。event.jsonの中身はごくシンプルなJSONです。

{
    "foo": "bar"
  }

実行するとこんな感じのログが自動的に出力されます。ちょっと見方に悩むかもですが、最初のエントリがイベントの中身のダンプを含むログで、2行目が例外発生時のスタックトレースですね。

{
  "name": "jeffy",
  "msg": {
    "foo": "bar"
  },
  "args": [],
  "levelname": "INFO",
  "levelno": 20,
  "pathname": "/usr/local/lib/python3.8/site-packages/jeffy/handlers/common.py",
  "filename": "common.py",
  "module": "common",
  "exc_info": null,
  "exc_text": null,
  "stack_info": null,
  "lineno": 30,
  "funcName": "wrapper",
  "created": "2020-06-10 10:42:23,786",
  "msecs": 786.0274314880371,
  "relativeCreated": 20.52927017211914,
  "thread": 140072547170112,
  "threadName": "MainThread",
  "processName": "MainProcess",
  "process": 93166,
  "aws_region": "ap-northeast-1",
  "function_name": "jeffy-sample-dev-decorator_sample",
  "function_version": "$LATEST",
  "function_memory_size": "1024",
  "log_group_name": "/aws/lambda/jeffy-sample-dev-decorator_sample",
  "log_stream_name": "2016/12/02/[$LATEST]f77ff5e4026c45bda9a9ebcec6bc9cad",
  "correlation_id": "1e1ca4b6-a204-4f05-b00d-53540d649570"
}
{
  "name": "jeffy",
  "msg": "division by zero",
  "args": [],
  "levelname": "ERROR",
  "levelno": 40,
  "pathname": "/usr/local/lib/python3.8/site-packages/jeffy/handlers/common.py",
  "filename": "common.py",
  "module": "common",
  "exc_info": "Traceback (most recent call last):\n  File \"/usr/local/lib/python3.8/site-packages/jeffy/handlers/common.py\", line 32, in wrapper\n    result = func(event, context)\n  File \"./decorator_sample.py\", line 6, in handler\n    return 1/0\nZeroDivisionError: division by zero",
  "exc_text": null,
  "stack_info": null,
  "lineno": 36,
  "funcName": "wrapper",
  "created": "2020-06-10 10:42:23,786",
  "msecs": 786.2870693206787,
  "relativeCreated": 20.788908004760742,
  "thread": 140072547170112,
  "threadName": "MainThread",
  "processName": "MainProcess",
  "process": 93166,
  "aws_region": "ap-northeast-1",
  "function_name": "jeffy-sample-dev-decorator_sample",
  "function_version": "$LATEST",
  "function_memory_size": "1024",
  "log_group_name": "/aws/lambda/jeffy-sample-dev-decorator_sample",
  "log_stream_name": "2016/12/02/[$LATEST]f77ff5e4026c45bda9a9ebcec6bc9cad",
  "correlation_id": "1e1ca4b6-a204-4f05-b00d-53540d649570"
}

(省略)

その他にもデコレータはいくつか用意されています。例えばKinesisやSQSのイベントをパースするなんてのはそれこそLambda関数を書く場合に頻発する処理なんですがそのあたりをやってくれてアクセスが楽になります。以下はSQSの場合です。

通常、SQSのイベントってRecordsに配列でデータが渡されてきます。

{
    "Records": [
        {
            "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
            "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082649183",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082649185"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        },
        {
            "messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
            "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082650636",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082650649"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        }
    ]
}

通常はこれをパースしてこの中のbodyだけを取り出して処理するといったようなことが必要です。それをこのデコレータでは簡単にしてくれるってことです。

取り急ぎこんな感じのコードを用意してみました。期待としてはbodyの値が取り出せることです。メッセージはひとまずSQSのコンソール上で送りました。

from jeffy.framework import get_app
app = get_app()

@app.handlers.sqs()
def handler(event, context):
    return event['body']

が、こんなシンプルなコードなんですが全然思ったように動かず。。。json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)っていうお決まりのアレが出てしまうんですよね。

ふと、後述のboto3のラッパー経由で送らないといけないのかも?と思いそれを試してみるも今度はKeyErrorが出ます。つまりbodyっていうKeyがないって言われてるんですね。

まずそもそもまだドキュメントが充実しているとは言えず、どういうデータがどうパースされるのか全然わからず小一時間ほど悩みました。悩んだ結果、時間切れです。わかってません。現時点では正直お手上げです。

ということでIssueを切っておきました。この辺りは初期OSSあるあるってことで長い目で見ていきたいと思います。

トレース

トレース用のIDを渡すようにboto3のラッパーが提供されてます。このあたりの活用方法とか、X-Rayとの棲み分けというか使い分けとかは気になるところです。今回はSQSで試してみました。

まずは送り側。sqs-publish.pyというのを作り、ここにこのラッパーを使ってます。

from jeffy.framework import get_app
from jeffy.sdk.sqs import Sqs

def handler(event, context):
    Sqs().send_message(
        queue_url=os.environ['QUEUE_URL'],
        message='hello world'
    )

これでデプロイして実行してみます。送り側についてはこのsend_message()がどういう仕様なのかドキュメントには書かれていないのでさっぱりわからなかったのですが、きっとmessageで指定した文字列がSQSのメッセージではbodyの中に入ってくるんだろうと想像して試したところ、実際にはbodyの中にcorrelation_idとともにJSON形式で格納されてました。

こんな感じ。

{
    "correlation_id": "",
    "item": "hello world"
}

見ての通りcorrelation_idというフィールドはあるものの値は入ってないです。これが不具合なのかはちょっとわかってません。また、送った文字列がbody.itemというフィールドで入ってくるのは想定外でしたが、まあそういう仕様なんでしょう。今後はここが自由に設定できるといいかもしれません。

受信側は前述のコードをデプロイしていたのですが、前述のとおりうまく動いてないです。。。このあたりはアップデートがあればまた試してみます。

まとめ

今回使ったコードはこちらに置いておきました。

github.com

なお、今回は全てを試したわけではないです。他にもAPI GatewayやS3を利用するときのデコレータやバリデータなんかも存在しています。

Jeffyはいわゆるフルスタックなアプリケーションフレームワークみたいなものというよりは現時点では面倒な実装を楽にしてくれるユーティリティに近いと言えますね。これが今後どういう風に進化を遂げていくのかわからないけど応援していきたいと思います。あとはAWSのようなクラウドで利用するにあたって、現状ではリソース定義やデプロイ周りとは切り離せないと思うのでそのあたりをこのフレームワークではどういうアプローチにしていくのかも興味ある。今の所はServerless Frameworkだったり、AWS SAMなどとの共存、併用ってことになると思うけど。そういう意味ではChaliceとの併用が一番強力かもしれない。しらんけど。

正直、まだ不安定な感は否めません。でもこのあたりはきっと時間が解決してくれると思います。あとはドキュメント周りですね。その辺も初期リリースなので仕方ない部分もあるかと思ってます。余力があれば僕もコントリビューションしていきたいところです。

ところでJeffyという名前の由来はなんだろうか? また、現状ではJeffyって単語でググるとよくわからないキャラクターの動画で検索結果が埋まってしまうようなのでこの辺もなんとかしていかないといけないかも。

©Keisuke Nishitani, 2020   プライバシーポリシー