SPAのOpen Graph Protocol 対応について。さらにCloudFrontを経由した場合についてのつらい話。
もう半年以上前になってしまうけど、この話題。
サーバーサイドレンダリング不要論 - Qiitab.hatena.ne.jpogp出すためにUAを見てアプリケーションサーバーに投げたりしてるけどcloudfrontでは既定でUAが書き換えられちゃうのでキャッシュヒット率落ちるのを覚悟の上でUAを通すという辛い状況。
2016/12/24 17:32
client → cloudfront → ELB → EC2(nginx → gunicorn )
という構成。
- nginxのリバースプロキシにて
/api
はgunicornにルーティング - それ以外は try_filesで /index.html を返すという設定
基本的にはこれで動く。しかしOGPが問題。この作りだとOGPの生成にはJavaScriptが動く必要があるが、twittterやFBのクローラーはJavaScriptを解釈しない。なので、nginxでUser-Agentを見てSNSのクローラーだった場合はgunicornに処理を委譲しOGPのみを描画したドキュメントを返すようにした。
if ($http_user_agent ~ "facebookexternalhit") { ・・・ proxy_pass http://127.0.0.1:8000; ・・・
ところが、User-AgentはCloudFrontの既定の設定だと"Amazon CloudFront"に書き換えられてしまい、上記の判定ができない。仕方ないので、以下のようにCloudFrontでUser-Agentヘッダを通すよう設定した。*1 これで判定は通るようになる。しかしUser-Agentを通したことでキャッシュヒット率は落ちる。うむー。SNSのクローラーがJavaScriptを動かすようになるか、CloudFrontが CloudFront-Is-Crawler-Viewer といったヘッダを用意してくれるとありがたいんだけど。
*1:ちなみに画像にあるようにCloudFront-Is-*ヘッダも使ってみたのだけど、今回の要件には使えなかった
let's encryptで証明書を取得する際はIP制限を外しておく必要がある
メモ書き。
EC2(Amazon Linux)でlet’s encryptからSSL証明書を取得した。基本的には以下の記事の通りにやればOK。 tkuchiki.hatenablog.com
certbot-auto を実行する際、最初セキュリティグループでhttpをアクセス制限していたのでスクリプトが失敗していたが、外したら成功した。 apacheのログには以下のようなものが記録されていた。
66.133.109.36 - - [08/Jun/2017:00:52:18 +0000] "GET /.well-known/acme-challenge/ランダム文字列 HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
考えてみれば当たり前なんだろうけど。。ググると、アクセス元の66.133.109.36
は固定されたIPのようなので、次回からはこのIP指定でアクセス制限しても良いかもしれない。
pypiデビューした
Pythonistaなら誰もがあこがれる(よね?)、pypiパッケージへのデプロイをビクビクしつつやってみた。
諸事情でStackPathのAPIを叩きたかったのだけどPythonのAPIがなかったのでやってみた。実際にはStackPathの前身であるMaxCDNのAPIをForkするだけだったので胸を張ってパッケージオーナーとは言いづらい。。。お手軽さとしてはpypiデプロイ初体験として最適だったと思う。
ところでStackPathはフリープランが無くて試用期間が2週間しかないので、それ以降は自腹を切らんとメンテできない。どうしようかな。
実際のpypiへのデプロイ手順はこちらのとおりなので特に書くことはございません。。。(ぉぃ qiita.com
世界でいちばん簡単な Pythonプログラミングのe本[最新版] Pythonアプリ作りの考え方が身に付く
- 作者: 金城俊哉
- 出版社/メーカー: 秀和システム
- 発売日: 2017/03/21
- メディア: 単行本
- この商品を含むブログを見る
初めてプルリクを作ってmergeしてもらった。
ショボい修正だけど嬉しいもんですね。django1.10からmiddlewareの書き方がちょっと変わった(正確には新しい書き方ができるようになった)ことに対応するためのプルリクを出しました。
しかしMiddlewareMixinはどうしてdeprecationモジュールに入っているんでしょう。このmix-inを使わずにメソッドを直接実装しろってことなんだろうか。
django-crequestというのは、requestオブジェクトを本来参照できない場所で参照するためのものです。modelとかutil的な関数でrequestを参照できるようになります。ASP.NETでいう System.Web.HttpContext.Current のようなやつ。ご利用はほどほどに。
追記:migrateをスキップすることでDjangoのunittestを高速化する
この続きです。
結論を先に書くと、以下のsettingsでテストを動かす。テスト用のsqlite3ファイルは使わない。 *1
from .base import * DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': ':memory:', } } # MIGRATION_MODULESは各installed_appsにある名前をkeyに、当該appのmigrationファイルのモジュール(既定ではmigrationsモジュール)をvalue指定した辞書。 # 以下のクラス、どんなキーを指定しても辞書に存在し、どんなキーを指定しても`nomigrations`を返す辞書を作っている。 # 'nomigrations'モジュールは存在しないので、既存のmigrationファイルは見つからずにmigration未済みという扱いになる。 class DisableMigrations(object): def __contains__(self, item): return True def __getitem__(self, item): # return 'notmigrations' return False # django 1.11にも対応するにはこちらで MIGRATION_MODULES = DisableMigrations()
ドキュメントを見ると、
When using SQLite, the tests will use an in-memory database by default
とあるので、ファイルを指定しても :memory:
で実行されるんだろうか。
また、core/management/commands/migrate.pyやdb/migrations/loader.pyを見るに、migrationファイルが見つからない場合はその場でmigrationファイルを作って実行してくれるようだ。
Two Scoops of Django: Best Practices for Django 1.8
- 作者: Audrey Roy Greenfeld
- 出版社/メーカー: Lightning Source Inc
- 発売日: 2015/05/15
- メディア: ペーパーバック
- この商品を含むブログを見る
長野市unofficialごみ収集カレンダーアプリを作った話(データ調達編)
突っ込みどころはありまくりだけど、アプリがどうにか実用レベルになったので記事を書きます。
初めてスマホアプリを作りました。
Xamarin製です。Xamarinにかんしてはまた別の記事で書きます。ここではアプリ内で使っているカレンダーデータをどう調達したかを書きます。
アプリを作るきっかけ
この記事を見たのがきっかけです。
ごみ分別アプリ(信州大学学生が作成しました。) - 長野市ホームページ
このアプリを使ってみると、通知機能がありませんでした。我が家では私がごみ出し担当なのでその日の朝に何のごみを出せる日なのかを通知してほしいのです。この記事に
長野市では、開発段階から行政情報を提供し
とあり、調べるとカレンダーはPDFで公開されていました。
http://www.city.nagano.nagano.jp/site/kateigomi/121416.html
これはプログラムでは扱いづらい。そこで生活環境課にメールしexcel形式での公開を依頼してみたところ、2ヶ月ほどして来年度平成29年度のデータを公開していただけました。ありがたや〜。
アプリで使っているカレンダーデータはこちら。
アプリでデータを使うに至るまでの所感
ちょうど同じようなタイミングで、祝日データの公開について話題になりました。
最新の国民の休日は内閣府から供給されるCSVを読めばわかることがわかった。これがオープンガバメントだ。 https://t.co/zCgGcMggmg pic.twitter.com/KeZKXwl20p
— にゃんだーすわん (@tadsan) 2017年2月21日
最初このつぶやきを見たときは、ご多分に漏れずITリテラシーの低さを残念に思ったのですが
人間が印刷したりして扱う形式とプログラムが処理する前提で公開する形式は違うほうがいいわけで、その変換は自動化なりで効率化されてないと、担当者やってらんねーと思うんですよね。現場努力でどうにかするみたいなのはなんかおかしい
という指摘をしている方がいて、たしかにと納得しました。実際、市に公開いただいたxls形式のごみカレンダーはまだプログラムでは少し扱いにくいです。列が分かれていたり日付セルに◯があって日付型でなくなってしまっていたり。人間には見やすいのですけどね。
「変換は自動化なりで効率化」ここを誰がやるのか。今は我々コンピュータ屋の仕事なのでしょう。今回は、扱いやすいJSONにするためにparserを書きました。
GitHub - koty/nagano_gomi_calendar
でも将来的には現場の人が片手間にできるようになるといいなと思います。車だってたまにはタクシーを使うけど多くは自分で運転するじゃないですか。小学校でのプログラミング教育必修化に期待しています。