Twitterの名前を現在のお天気と連動させるアプリを公開した🌥️ https://t.co/gPhy7iVV9a …
— 山本一成🌤️Ponanza (@issei_y) November 9, 2018
お天気絵文字をTwitterの名前に表示する機能をみんなが使えるようにしました。
概要
みなさん、おはよう、こんにちは、こんばんわ。
【Twitterの名前を5分毎に東京の天気⛅☂☃と連動させるサーバレスプログラムを書いたら色々知らないことが出てきた話】の続きです。
このサービスをちゃんとみんなが使えるようにしたという話です。
知らないことがたくさんあるので、間違いなどありましたらコメント欄に優しく書いてください😆
Twitterの認証
以前の記事では自分のTwitterアカウントだけ操作できればよかったのですが、今回は他のユーザーの方も操作できるようにしないといけないです。
それにはOAuthという仕組みが必要そうです。
OAuth(オース)とは？
「OAuthとはTwitterなどの認証に使うシステムです」とここまでは自分も知っていたのですが、いざ実装してみようと思うとライブラリのチカラを借りても結構苦戦しました。
なにより概念の理解が難しい。
なんと、2本用途が異なるURLを用意する必要があるみたいです。
Amazon API Gateway
Webサーバー立てる時は、クラウドインスタントを借りるか、グルーバルIPを買い、DNSに登録して、物理サーバーを用意するといった方法が主流だったと思います。
しかし最近はURLを設置して、入力と出力だけをスキな言語で書けば良いといったサービスがあるみたいですね。
今回利用したのはAmazon API Gatewayというサービスです。下の図のように設定すると、処理がAWS Lambdaの方に飛んでいきます。
OAuth処理 Step1
2つ前の図のStep1の部分です。こちらがユーザーの入り口になります。こちらのURLにアクセスがあったら、TwitterへのアクセスをするURLを発行してHttpのステータスコードを302にして、リダイレクトします。
このへんの処理は前回同様、C#のCoreTweetで作られています。
作者様ありがとうございます🙏🙏🙏
さらにユーザーが認証した時のcallbackのURLも同時のTwitterに伝えます。
このURLはStep2でつかうURLになります。
またRequestTokenとRequestSerectもDynamoDBに保存しておきます。
OAuth処理 Step2
2つ前の図のStep2の部分です。ユーザーからの認証が降りた場合、step1で呼ばれたcallbackのURLが呼ばれます。
そこで先程保存したRequestTokenとRequestSerectを突き合わせてユーザのtokenを得ます。
かなり複雑ですが、これでユーザーの安全性が少しでも向上するのならば素敵なことですよね。
ちなみにこの時ユーザーの発信元のIPがHttpのヘッダーのX-Forwarded-Forに乗っているので、可能ならばそこからある程度場所を推定したいです。
みんな登録してくれたのに、東京の天気予報だけだと味気ないですからね。
その後は実際に名前を変更していきます。
例えば「山田@花子」が「山田☃花子」になります。
IPからおおよその位置情報
IPからおおよその発信元を推測するサービス、調べるといっぱいあるのですが、今回はMaxMindというものを使ってみました。
IP入れたら、国と都市名などを返してくます。
ちなみに有料です。$25払いました😫
ちなみに割と適当みたいで、私東京にいるのですが、スマホで位置情報を調べたらKawasakiとでました。
まあでもそんな詳細に知りたいわけでもないですし、これくらいでいいでしょう（謎)
5分おきに更新
登録時に名前に天気情報を付与しただけでは、実際の運用じゃないですよね。
ということで AWS LambdaでDBをすべて調べて、各ユーザの名前のその人が登録した場所ごとにお天気情報をUpdateしていきます。
具体的にどのようにやったかというのは前回の記事を参考にしてください。
海外からの利用者も
海外からの利用者の方もいるみたいですが、無事動いているみたいです。うれしい
ブラジル・サンパウロで使わせていただいていますが、きちんと今の天気と連動しています。今日は晴れ間が出たり雨が降ったりと変わりやすい天気でしたが、それでもバッチリでした。楽しい機能を提供いただき、ありがとうございます！
— 🇧🇷 Tsukasa Hirano ⛅ (@tsukasahirano) November 10, 2018
ちょっと失敗しちゃったなと思う点
完全に調べきれてないのですが、どうもお天気APIを呼ぶのが結構時間がかかっているので、このサービスあまり高速に回っていません。
AWSの人に相談したところ、向こうのAPIは多分アメリカの東海岸or西海岸にあるので、ちゃんとAPIの場所をある程度特定して、そこでデプロイしたほうが良いと言われました。
何も考えずTokyoリージョンのAPIGatewayとDBを設置してしまってちょっと失敗しちゃいました。
また時間があれば移設作業をしよう（願望）
ちょっと失敗しちゃったなと思う点2
DyanamoDBになんでも放り込む設計にしちゃったのですが、全員の天気を更新する時にfull scanが走ってしまいます。
あんまり良い設計ではない気がしたのですが、結局どうすればいいわからないまま。
まあでもでそれほど大きなデータサイズでもないしいいか（よくない）
軽量サーバーフレームワークの代替に？
sinatraやnancyといった軽量サーバーフレームワークを個人でも仕事でもちょくちょく使っていたのですが。（※余談ですがPonanzaの開発にも使ってました）
API Gateway を使ってみてその簡単さや精神的負担のなさに関心しました。簡単なAPIサーバーならインスタンス借りてフレームワーク入れてデプロイするという従来の方法以外にも、クラウドベンダー系のこういったサービスを使ってみるのも検討の価値がありそうです。
プログラミング is すごい
このアプリ、知らない技術のことを色々調べながら、数日頑張ってなんとかできました。先程データベースで確認したら利用者数は2000人を超えててびっくりです。
このアプリが皆さんの生活を劇的に変えることはないでしょうが、毎日の幸せに+1👍できるものになったら嬉しいです。
これを見て難しそうだけどプログラミングやってみたいと思った方はぜひチャレンジして世界をちょっぴり良くするアプリを作りましょう。
🌏名人に勝利した将棋プログラムの作者
— 山本一成🌒Ponanza (@issei_y) April 18, 2018
🌍AIやプログラミングについて呟きます
🌎愛知学院大学特任准教授