rch850 の上澄み

技術的な話題とか、雑談とか。タイトルを上澄みに変えました @ 2020/09/02

インフルエンザ様疾患の発生について

今朝、福井県で学級閉鎖が出たってニュースを聞いて、調べてみたらこんな PDF を見つけた。

内容はこんな感じで、どこの小学校で起こったか、何年生の合計何人中何人が患者なのか、いつからいつまで学級閉鎖なのかといった情報が書いてある。これは役に立ちそう。

f:id:rch850:20141128012925p:plain

タイトルにもなっている「インフルエンザ様疾患」ってなんだろーって調べてみたら、文部科学省にこんなページを見つけた。

なるほどなるほど、国として報告していく仕組みがあるわけね。2009年のパンデミックの際に、だいぶ整備されたんだろうなぁ。

いろいろリンクを辿って行くと、NESID やら iNESID に情報を集める方向だというのがわかってくる。インフルエンザ様疾患発生報告について(iNESID版) なんかは、かなり詳しく書いてある。

1 都道府県等は、次に掲げる情報を、1週間分(月曜日から日曜日まで)集計し、 翌週の火曜日(休日の場合はその翌営業日)までに報告することとする。

・ 第2の3で把握したインフルエンザ様症状を呈する患者の集団発生に係る 情報

2 1の報告は、暫定的感染症サーベイランスシステム(iNESID)で行うも のとする。

だとか

1 第2の4の検査を実施し、新型インフルエンザ(A/H1N1)が陽性であっ た場合、地方衛生研究所は、感染症サーベイランスシステム(NESID)の「病 原体検出情報システム」における病原体個票及び集団発生病原体票にデータを登 録する。

だとか。なるほど、NESID が「感染症サーベイランスシステム」で、iNESID が「暫定的感染症サーベイランスシステム」って事なんだな。こんな事がわかってくると、どんなシステムだか気になるじゃん?ってわけで、検索したら、症候群サーベイランス - 感染症 早期探知システムのご紹介というものが出てきた。名前が「感染症」ではなくて「症候群」と、ちょっと違うけど、まぁいいや。

サイトには学校欠席者情報収集システムなんてものへのリンクがある。これは気になる!ポチッ!

f:id:rch850:20141128020037p:plain

おー、すごいすごい。全国で欠席者が出てるかどうかがひと目で分かる。学級閉鎖も見られるみたいなのでポチってみると、

f:id:rch850:20141128020616p:plain

f:id:rch850:20141128020627p:plain

なるほどねー。未実施、非公開のところが結構あるけど、そこそこ役立ちそう。

iNESID の情報が参照できれば、かなり詳しくインフルエンザの流れを追えそうだなー。

CloudFlare で Heroku に zone apex を向ける

sokuhotel.net みたいな、zone apex だとか root domain だとか呼ばれるあれ、Heroku で使いたいときは CloudFlare を使うと無料で簡単ですね。

Heroku のドキュメント (Custom Domains | Heroku Dev Center) では、下の通りいくつかの方法が案内されている。

f:id:rch850:20141102050204p:plain

この中で一番知ってたのが CloudFlare だったので、CloudFlare で適当に設定。この場合に設定するのは

まず CloudFlare 側はこんな感じで設定。

f:id:rch850:20141102052904p:plain

zone apex の A レコードで最初から入ってる場合は、それを消してやらないと CNAME を追加できないので注意。あと、今回は特にアクセスを高速化したりしたいわけじゃないから、CloudFlare 自体の機能は切ってある(雲アイコンがグレー)。

CloudFlare で zone apex に CNAME を設定すると、設定上 CNAME となっているものの、実際の名前解決では A レコードとして解決される。これが CNAME Flattening ってやつで、zone apex を使える理由だ。zone apex に A レコードじゃなくて CNAME を設定できちゃうと色々と問題になるからね。

Heroku のほうは、zone apex を Domains に追加してやる。

f:id:rch850:20141102051845p:plain

既存のリンクが壊れちゃってもしゃーないから www を残してるけど、最初から使う気が無ければ設定しなくてもいいと思う。

最後にドメインレジストラ側の設定で、NS レコードを CloudFlare に向ける。VALUE DOMAIN だとこんな感じ。

f:id:rch850:20141102052058p:plain

この3つの設定が終われば、そのうち zone apex でサイトにアクセスできるようになる。

会員登録フォームで再入力させるのはパスワードではなくメールアドレス

Facebook にログインしてない状態でアクセスするとこんな画面が出てくる。

f:id:rch850:20141024111659p:plain

登録フォームがいきなり出てくる、グロースハックとしてはおなじみのパターンなんだけど、エンジニアが注目すべきなのは再入力を促している箇所。このフォームではメールアドレスまたは携帯電話番号の再入力を促している。

再入力自体そもそもいらなくね?みたいな話は置いておいて、なぜパスワードではなくメールアドレスを再入力させるのか?

答:間違ったら困るのがパスワードではなくメールアドレスだから

Facebook に限らず、最近のサービスはパスワードを忘れてもメールアドレスからパスワードをリセットできる。でも、登録時にそのメールアドレスを間違えてしまったら……残念なことにパスワードリセットのメールがどこかの誰かに届くだけだ。実際、自分のメールボックスにも誰かの LINE のパスワードリセットのメールが届くことがある。かわいそうに。

パスワードの再入力フォームを作ってる時間があるなら、その時間をメールアドレスの再入力フォームに費やそう。そうすればかわいそうな人は減るはずだ。

2014年10月のMySQLセキュリティアップデート

巷では Amazon RDS リブート祭りになってますが、その原因となった MySQL脆弱性とは何なのか。

Oracle のアドバイザリから、攻撃時の認証が不要となっていた9つの脆弱性をピックアップ。

CVE Base Score 最悪の影響などの概要
CVE-2014-6491 7.5 MySQL Server での任意のコード実行を含んだ、MySQL Server の奪取
CVE-2014-6500 7.5 MySQL Server での任意のコード実行を含んだ、MySQL Server の奪取
CVE-2014-0224 6.8 攻撃は難しい。いくつかの MySQL Server での update, insert, delete の実行、MySQL Server がアクセスできるデータの一部のリードアクセス、MySQL Server の部分的な DOS
CVE-2012-5615 5.0 MySQL Server がアクセス可能なデータの一部へのリードアクセス
CVE-2014-6559 4.3 攻撃は難しい。MySQL Server がアクセス可能なデータ全てへのリードアクセス
CVE-2014-6494 4.3 攻撃は難しい。MySQL Server のハングアップや連続したクラッシュ(complete DOS
CVE-2014-6496 4.3 攻撃は難しい。MySQL Server のハングアップや連続したクラッシュ(complete DOS
CVE-2014-6495 4.3 攻撃は難しい。MySQL Server の連続したクラッシュ(complete DOS
CVE-2014-6478 4.3 攻撃は難しい。MySQL Server がアクセスできるデータの一部への update, insert, delete

MySQL Workbench 6.2.3 がよかった(Pin Tab, Visual Explain)

MySQL Workbench のとあるレグレッション(だと思う)をだいぶ前に報告して、それに対して「6.2.3 で試してみて」って返信がついてたから、入れてみたんだけど、これって GA だったのね。

個人的に感じたことのまとめ

よかった

  • 6.x でカラム幅が短くなるデグレが解消されたっぽい
  • Pin Tab でクエリの結果を複数保持できるようになった
  • クエリ実行時に、常に実行計画が表示できるようになったっぽい。あと見やすくなった

だめっぽい

  • 6.x で雑なクエリ(select * from hogehoge)を打った時に固まることがある現象はまだ起こる

詳しい説明は公式の新機能リストに譲ります。

Pin Tab は、クエリの結果を保持できる機能。これずっとほしかったんだよなー。

f:id:rch850:20141001095440p:plain

Visual Explain は、だいぶ以前よりも見やすくなった。あと、普通にクエリを実行したときにも勝手に表示されるようになったと思う。これはもしかしたら以前からあったかも?

f:id:rch850:20141001094442p:plain

ちなみにレグレッション(だと思う)は直ってませんでした。今後に期待!

F高専のクラスアイドル Nanamin がかわいい

某F高専の学生が作ったキャラクター Nanamin の LINE スタンプが公開されてた!おめでとう!

ってもう2週間以上前の話ですね。Nanamin かわいい。

Nanamin について詳しくは Nanamin公式HPをチェックしよう。

aws-sdk-java の PR 通ったけど空気ってなんだろう

朝からおはよう Rails を見てて「モンキーパッチやめろ」が連呼されてたから、upstream への pull request の話題をひとつ。

JavaAWS 使うときに使う AWS SDK for Java に、ちょっとした機能が欲しくなって Pull Request を送って取り込まれたってのがもう2ヶ月ほど前の話。Contributors に名前が載ったよ。やったね!

で、最近になって流れてきたツイート。

うん、空気ってわからん。

まず PR 送る前に、コミュニティの空気を読むために他の PR をちょいちょいチェックしてみたんだけど、割とマージされないどころかコメントすらついてない PR がそこそこあって……もしかして自分の PR もこの中に埋もれるんじゃないか!?という未来が見えたり見えなかったり。

で、自分なりに空気を読んだ結果、「これがあればきっと便利!」とだけ書いて PR を送った。

f:id:rch850:20140920113842p:plain

数日でライセンス確認のコメントがついて、いいよって答えたら1ヶ月弱でリリースされてた。

PR の中で、追加機能の有用性だとか、詳しい仕様だとかを書かなかったのは正解だと思ってる。有用性を判断するのは自分じゃないし、詳しい仕様なんてコードを読めばわかるし、分からないならコードがまずい。空気を読むのはほどほどに、ちゃんとコードを書けば大丈夫なんじゃないかなぁ。