APNsのプッシュ通知で利用するプロバイダ証明書関連の各種ファイル形式について調べてみたメモ
前の記事では、APNsとプロバイダの間の接続信頼の話をしました。この記事では、接続信頼の確認に使う証明書関係のファイルの話をします。
複数の鍵や証明書をまとめて扱うための個人情報交換( .p12 )
まず、Push通知の証明書関連で調べているとよく出てくる .p12 という拡張子のファイルですが、これは日本語では 個人情報交換 と呼ばれています。
個人情報交換は、その内部に複数の鍵や証明書をまとめて格納することが可能で、パスワードでそれらのファイルを保護します。
たとえば、よくある1つのiOSアプリ用に使うプッシュ通知用の証明書だと、キーチェーンから書き出した .p12 ファイルの中にPEM形式の鍵と証明書が含まれています。なので、こちらの記事のように、 .p12 のファイルから .pem のファイルを書き出したりします。
証明書のデータ構造のエンコーディング( PEM, DER )と公開鍵基盤用の規格 X.509
PEM 形式の鍵、証明書は鍵、証明書のデータの部分がBase64でエンコーディングされています*1。
これに対し、鍵、証明書のデータの部分がバイナリエンコーディングされているのが DER 形式の鍵・証明書で、 PEM, DER 形式のファイルに含まれる証明書・鍵のデータは ASN.1(アセンワン) という言語で定義されています*2。
もう少しかっちり書くと、 X.509 という公開鍵証明書と証明書失効リストを含む公開鍵基盤(PKI)について定義される規格があり、その中で PKI 用証明書のエンコーディングには ASN.1 DER エンコーディングが使用されるように定義されています*3。また、 X.509 に基づいて作成・運用される証明書が X.509 証明書 と呼ばれているみたいです*4。
APNS - プロバイダ間の接続信頼を確認する際は、この X.509 証明書のデータを利用します。その際、エンコーディングされた文字列ではなく ASN.1 で定義された型のオブジェクトまでデコードする必要があります。
証明書署名要求( CSR )を使ってAppleからの署名によりApple公認のプロバイダであることを証明する
順番はやや異なりますが、ここまで
X.509という公開鍵基盤(PKI)について定義する規格があるX.509の公開鍵証明書はASN.1という言語で*5型が定義されている個人情報交換(.p12のファイル) で、証明書のデータをエンコーディングしたPEMと鍵のデータをエンコーディングしたPEMなどを合わせて格納する
という話をしました。では、鍵と証明書*6の .pem ファイルが中に入った .p12 ファイルでありさえすれば、どんなものでも APNsとの間の接続信頼の確認に使えるのでしょうか。
もちろん、そうではありません。
APNsとの間の接続信頼を確認するためには、Appleと契約を結んだ組織に属していることを証明する必要があります。そして、そのために接続信頼の確認に利用する証明書にはAppleの署名が必要です。
公開鍵証明書に特定の組織(公開鍵基盤の言葉でいうと、認証局)の秘密鍵で電子署名をしてもらう。そのために認証局へ提出するファイル*7を 証明書署名要求(CSR: certificate signing request) といいます。
CSRを用いたApple側の署名入り証明書作成手順について備考
最後に、公開鍵基盤(PKI)の証明書署名要求(CSR)を用いた証明書の作成手順をAPNsの具体事例にあわせておさらいしておきましょう。
まず、IPAの資料によると証明書の発行プロセスは大別して
- 加入者(証明書が発行される側。APNs - プロバイダ間でいうとプロバイダ、アプリ開発者のほう)が鍵ペアを生成する方式
- 登録局が一括して鍵ペアを生成する方式
の2通りあります。
この記事などの手順にあるように、APNsから証明書発行してもらうプロセスはプロバイダ側がキーペアを含めたCSRを作成するところから始まるので1の方ですね。
まず、1. の手順に「加入者が鍵ペアを生成する」について。APNsの証明書を作成する場合は、「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest ファイルを作成します。
作成した .certSigningRequest ファイルをApple開発者アカウントの管理画面からAPNsのシステムへアップロードすることが、KPIでいう加入者の認証局に対する証明書の発行申請にあたり、アップロード後にダウンロードした .cer ファイルが Apple側の署名がなされた証明書となっています。
ところで、「加入者が鍵ペアを生成する」の文言と 「「キーチェーンアクセス > 認証局に証明書を要求...」から .certSigningRequest ファイルを作成」 の内容があってないですね。
実は「キーチェーンアクセス > 認証局に証明書を要求...」をクリックしたときの画面をみてみると
のようになっており、 .certSigningRequest ファイルを作成する前に秘密鍵と公開鍵のキーペアを生成しているようです。
この秘密鍵はキーペアを生成したMac(システム)に配置され、キーチェーンからのみアクセスできるようで、他のMacに移行したりプッシュ系のmBaasを利用する場合などはAppleから発行された証明書( .cer ファイル)に秘密鍵を含めて .p12 ファイルに書き出す必要があります*8。
参考
- https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html
- https://www.ipa.go.jp/security/pki/034.html#_Toc3020776
- https://qiita.com/kunichiko/items/12cbccaadcbf41c72735
- http://www.geocities.co.jp/SiliconValley-SanJose/3377/
- https://www.sambaiz.net/article/135/
- https://dev.classmethod.jp/smartphone/iphone/apple-certificates-summary-and-etc/
*1:余談ですが、Base64でエンコードすると最後に=ってつくことありますが、それはデータがエンコード文字列の長さで表せる量に対して中途半端に短かった時の穴埋めなんだそうな https://ja.wikipedia.org/wiki/Base64
*2:DERの仲間にBER, CERがあり、DERはBERのサブセット http://www.geocities.co.jp/SiliconValley-SanJose/3377/
*3:https://www.ipa.go.jp/security/rfc/RFC2459JA.html
*4:みたいですってなんやねんって話ですが、PEMとかファイル形式で説明されていることが多くてちょっとだけ自信がない
*5:X.509証明書以外にもASN.1で定義されているものはあります http://www.geocities.co.jp/SiliconValley-SanJose/3377/
*7:データさえ渡せればいいので、ファイルとして送る必要は特にないが、Appleの開発者管理画面の画面がファイルとしてアップロードする形だったのでファイル表記
*8:https://dev.classmethod.jp/smartphone/iphone/apple-certificates-summary-and-etc/
APNsを利用する際に必要な2種類の接続信頼について
APNsを利用する際に必要な2種類の接続信頼
APNsを利用する際には証明書やトークンが必要ですが、それは認証のためです。
ドキュメント*1には、暗号化されたデータが正しく復号できるか、途中で改ざんされていないかみたいな確認にあたる暗号化検証とあわせて 接続信頼 と呼ばれています。
この接続信頼には
- プロバイダ - APNs間の接続信頼
- APNSにリクエストを送ってきた人がプロバイダー(=プッシュ送りたい人、アプリ作った人)であることを証明する
- これが確認できないと、プロバイダとAPNsの間でやりとりはできない
- APNs - デバイス間の接続信頼
- APNsから通知を受信するデバイスが、認証を受けたもののみであることを証明するためのもの
の2種類があります。
プロバイダーAPNs間の接続信頼
まず、プロバイダーAPNs間の接続信頼の話をします。
プロバイダーAPNs間の接続信頼には「トークンベースのプロバイダ接続信頼」「証明書ベースのプロバイダ接続信頼」があり、それぞれ接続信頼を確認するために必要な手順やプロバイダのサーバに配置するファイルが異なります。
トークンベースのプロバイダ接続信頼
- WWDC2016で公表された方式。
- こちらの記事の手順で管理画面で Apple Push Notification Authentication Key(Sandbox & Production) を発行し、その際にダウンロードする
.p8ファイルをサーバーに配置Apple Push Notification Authentication Keyの 有効期限は無期限 です(こちらの操作により無効にすることも可能)
- こちらの記事 に書いてあるような手順で
.p8ファイルから秘密鍵を取り出し、時刻を利用して認証に使うトークンを生成します - バンドルIDが記載されているすべてのアプリケーションにおいて同じ
Apple Push Notification Authentication Keyを使うことが可能です - 余談として、ドキュメントの セキュリティアーキテクチャ > プロバイダ－APNs間の接続信頼 > トークンベースのプロバイダ接続信頼に
鍵ペアを生成し、公開鍵をAppleに渡してください。秘密鍵はプロバイダ側で保持しと書いてあるものの、公開鍵をどうこうした覚えはなくて若干戸惑っていたり。。- これは推測ですが、秘密鍵がそのときDLする
.p8ファイルに入っているので、多分公開鍵はApple Push Notification Authentication Keyを発行した時にAPNs側に保管されているのでしょう。。
- これは推測ですが、秘密鍵がそのときDLする
トークンベースの接続信頼を利用する場合に送るリクエストの例
HEADERS
- END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0
host = api.development.push.apple.com
authorization = bearer eyAia2lkIjogIjhZTDNHM1JSWDciIH0.eyAiaXNzIjogIkM4Nk5WOUpYM0QiLCAiaWF0I jogIjE0NTkxNDM1ODA2NTAiIH0.MEYCIQDzqyahmH1rz1s-LFNkylXEa2lZ_aOCX4daxxTZkVEGzwIhALvkClnx5m5eAT6 Lxw7LZtEQcH6JENhJTMArwLf3sXwi
apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b
apns-expiration = 0
apns-priority = 10
apns-topic = <MyAppTopic>
DATA
+ END_STREAM
{ "aps" : { "alert" : "Hello" } }
- ヘッダーに接続信頼用の
authorizationキーがあります。 Apple Push Notification Authentication Keyは開発者アカウントと紐付いているすべてのアプリと紐付いているので、どのアプリ宛かを指定するためのapns-topicの指定があります。- デバイストークンの指定は、
:pathで行われています。
証明書ベースのプロバイダ接続信頼
- 証明書ベースのプロバイダ接続は、プロバイダ証明書(具体的には .p12 ファイルや .pem の中に含まれているデータ)で指定されている特定の1つのアプリケーションのためのものです
- 接続信頼の確認に利用する証明書は事前に作成します
- 証明書ベースの信頼を利用する場合、APNsが証明書失効リストを作成、管理しています*4
- 証明書ベースでプロバイダ接続信頼を行う場合、証明書を使うのはTLS接続確立までで、個々のリモート通知リクエストの時は通知先のデバイストークンだけヘッダにつければよいです
- トークンベースの接続信頼で使う
Apple Push Notification Authentication Keyと違い、証明書ベースの接続信頼で使うSSL証明書(.p12ファイル)は1年の有効期限があります
証明書ベースの接続信頼を利用する場合に送るリクエストの例
HEADERS
- END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0
host = api.development.push.apple.com
apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b
apns-expiration = 0
apns-priority = 10
DATA
+ END_STREAM
{ "aps" : { "alert" : "Hello" } }
- トークンベースの場合と違い、
authorizationキーはありません。 - 基本的に、証明書ベースの場合、証明書の中にどのアプリ用の証明書か含まれているため、証明書の中に記載されたトピックへのリクエストとして処理できるため、
apns-topicの指定がありません- 複数のtopic用の証明書の場合は
apns-topicの指定が必要です。
- 複数のtopic用の証明書の場合は
- デバイストークンの指定は、
:pathで行われています。
APNs－デバイス間の接続信頼
次にAPNs - デバイス間の接続信頼の話をします。
大枠を言うと
- iOSなどのデバイスの利用開始設定(アクティベーション時)に接続信頼に利用される暗号化証明書と秘密鍵がOSから提供される
- OSから提供された暗号化証明書と秘密鍵はキーチェーンに格納され、アプリケーションとは関係なしにAPNsとデバイスとの間の接続信頼に利用される
- (= デバイスとAPNsとの接続信頼のために、開発者がなにかする必要はない)
となります。
そうすると自分(プロバイダ)として関心があることは、このAPNs - デバイスが接続された上で、デバイスへのリモート通知リクエストに必要なトークンを取得することですが、この部分については開発者側で実装や設定が必要です。
iOSおよびtvOSでのデバイストークンの取得などを参考にアプリケーションがリモート通知リクエストを送るためにAPNsへリクエストを送り、結果を受け取る実装をし、また、Enable push notificationsを参考にアプリケーションがプッシュ通知を利用する設定が必要です。
参考
- Apple Push Notification サービス
- リモート通知サポートの設定
- Enable push notifications
- Golangで「プロバイダー認証トークン」を生成して、APNsにプッシュを送ろう
- Apple Push Notification Authentication Keyを発行しよう
*1:https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
*2:かといって接続のたびに再発行してほしいわけではない
*3:アプリのリモート通知以外にもVoIP通知などの用途があり、その場合アプリのbundle IDに .voip がついた値をtopicに指定する https://developer.apple.com/jp/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1
*4:これは、開発している時にはPush屋さんが失効時の挙動テストする時にAPNsのサンドボックスでの失効が遅い...(なんかSANDBOXの場合、半日くらい待ってる気がする) というくらいしか縁がないのではないか...
EMRのHiveのドキュメントを読むのが不自由だったので読み方からメモ
仕事で若干AWS EMR上のHiveにさわったので少しだけメモ。
ドキュメントの読み方とか頭いっぱいになってるとすっこ抜けて死んでいますが、EMRの他のサービスについても似たような感じに気をつければいいはずだ。。
マネージドサービスとはいえ、設定できる項目については基本の元々のソフトウェアの設定ファイルの名前とかが割と使えるようになっているかもしれないとか。。
EMR上に入っているHadoopその他のバージョンについて
RDSにはMySQLやPostgresをはじめとしたRDBSが、Elastic CacheにはRedisなどキーバリューストアがあらかじめインストールされているように、EMRには基本的にHadoopやApache Sparkがインストールされています。
このEMRにインストールされているバージョンはソフトウェアのバージョンはEMRのリリースバージョンごとに管理されていて、EMRのリリースバージョンに対するHadoopやApache Sparkのバージョンは https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html から確認できます。
Hiveの設定ファイルとAWS EMRのconfigのキーの対応
Hiveを叩くためにHiveServerやHiveServer2を使って~みたいな話が出てきた時に、Hive の設定ファイルとして hive-site.xml の内容が紹介されることがありますが、EMR上でHiveを利用する場合、 hive-site という Classification を利用して指定します。
// https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html
[
{
"Classification": "hive-site",
"Properties": {
"javax.jdo.option.ConnectionURL": "jdbc:mysql:\/\/hostname:3306\/hive?createDatabaseIfNotExist=true",
"javax.jdo.option.ConnectionDriverName": "org.mariadb.jdbc.Driver",
"javax.jdo.option.ConnectionUserName": "username",
"javax.jdo.option.ConnectionPassword": "password"
}
}
]
Hive JDBC Driverの利用について
Clouderaのとか、Apacheのとかあると思いますが、Amazonが用意してるJDBC Driverを使います。 ドキュメントはDLしたzipの中に入っています。。
Appleの証明書関連を調べるときに公式ドキュメントの「証明書」ページを読んでおくととても捗る
Appleの証明書関連を検索するとき、かなり検索しにくく感じるときがありますが、
のページに目を通しておくと公式ドキュメントのググラビリティが非常に上がります。というか、先に読んでおくもののはずなんですが、ググり方がわからなかったので、メモ。
また、上記ページの各種証明書がApple Developer AccountのどのフォームからDLされるものか、について追加でまとめます。
Apple Worldwide Developer Relations Certification中間証明書
ここのフォームからDLするだけだと拡張子が .cer なだけでどの種類の証明書かわかりにくいんですが、このファイルをDLした.cerを開いたとき、キーチェーンに追加されるのが
となっています。
Apple Push Notification Service証明書
俗称・Push通知用の証明書、 .p12 に書き出すやつ
Identifiers > App IDs > 特定のApp ID をクリックして下の方のEditボタンを押して出て来る
のフォームで作成・再作成・DLするもの。
iOS配布用証明書（App Store）/ iOS配布用証明書（社内用アプリケーション）
英語版のページと
Certificates - Support - Apple Developer
Provisioning Profile の作成フォームを見比べて
Provisioning Profile のこと。
みなさまにおかれましては、独自の証明書を使った認証の 利用者が不慣れな*1仕組みを実装、ならびにそのドキュメントを作成するときは拡張子(とサンプルファイル名)も書いていただけると非常に話がスムーズなので何卒よろしくお願いします。
現場からは以上です。
*1:調べてたら一般的な仕組みとわかってきた(また今度まとめよう...)ので訂正
RSpecでクラスの挙動や定数をテスト用のダミーにする、見慣れなかったマッチャ、普段は実行しないテストのスキップ、などの話
参加しているプロジェクトのRSpecを見ていたら見慣れないことがいろいろあったので、復習しておきます。
RSpecでクラスの挙動をダミー用のものにする
target_obj = double("target_obj") # initializeの文字のほうに深い意味はないらしい target_obj.stub(:string) { "Stub test" } # 以上は上と同じ target_obj = double("target_obj", :string => "Stub test") allow(target_obj)to receive(:post) # ダミーオブジェクトである target_obj に postメソッドを生やす # テストしたいメソッドの中で使われているクラスを初期化したらテスト用に用意したダミー実装が使われるようにする allow(Real::Target).to receive(:new).and_return(target_obj) # def testing_method # Real::Target.new.copy.string # end expect(testing_method).to eq "Stub test" # 所定のspecでだけ定数を置き換えたい stub_const("TARGET::CONST", 100)
参考
http://web-k.github.io/blog/2012/10/02/rspec-mock/ https://qiita.com/jnchito/items/640f17e124ab263a54dd
http://codenote.net/ruby/rspec/1800.html https://relishapp.com/rspec/rspec-mocks/docs/mutating-constants
match_array マッチャ便利かも
ActiveRecordから要素を取り出してくるけど、テスト用にベタがきする値と順序が一致していないので汚いコードを書いて... という記憶があったのでよさそう。
参考
https://qiita.com/jnchito/items/a4a51852c2c678b57868
RSpecで普段は実行しないテストをスキップする
describe Hoge do it "heavy test", type: :model, very_heavy_tests: true do # スキップ用のオプションはRails5で追加された type オプションの後に書きます hoge.should eq(fuga) end end describe Hoge do it "normal test", type: :model do # 書いてない場合は very_heavy_tests: false 扱いでこのテストは普段から実行される hoge.should eq(fuga) end end
RSpec.configure do |c| c.filter_run_excluding :very_heavy_tests => true end
参考
https://qiita.com/semind/items/cffd5c9e7ef9a108c871
現場からは以上です。
インフラエンジニアの教科書2を読みました
DockerとかAWSとか色々勉強しなければいけない感じなのですが、DockerやAWSの説明に出てくる用語がわからないということで、その辺りの基本的なことが載ってそうだし、薄いし、ということで「インフラエンジニアの教科書2」を読みました。
さらっとわかりやすい文体で書いてあるのですが、内容は
あたりから、使う順に引っ張ってきました、という感じで、やさしそうな顔して濃いです。濃さの割にすらすら読めるので、わかった気になってないだろうか、と1ページ1ページなかなか読み進められず2~3週間くらいかかってました。
個人的に、特にありがたかったのが2章のOSのところで、自分はこの本を読んで学んだのですが、短めにまとめたそれでさえかなり重たくて読み終わった後感覚としては結構手ごたえがあったんですが、自分が何に対して手ごたえを得たのかちょっと要領を得ない感じでもやもやしていたのが結構すっきりした気がします。
この本読んで、コード的にもうちょっとどうなってるの... って思ったらこの本をめくってみると楽しいかもです。
逆に4章は、ちょっとシャーディングがレプリケーションと同じノリで書かれていたことに対してやや驚いていて、検索で出てきてほしい結果がユーザやユーザの属する組織、みたいな単位を超えるかどうか、とか、11章の拠点間のデータ保存のところみたいな部分を検討してからでないとなんとも言えないのでは。。と思いました。
他には、6章のSSL通信の基本的なところの説明や8章のセキュリティ攻撃のところがわかりやすくて、SSL通信は長いことひっそり知ったかぶりしていたので、ほっとしたのでした。
以下、読書メモの中で印象的なところを置いておいて、現場からは以上です。
- 経路情報
- ルータがパケットを受け取るたびにそのルータが次の転送先を自動的に選んで送り出す
- ルータには次の経路を決めるためのルールが登録されている必要がある
- 各ルータが経路を決める手段
- スタティックルーティング
- ダイナミックルーティング
- 周りのルータと経路情報を交換し合うことで動的にルーティングが更新される
- IGPとEGPの2種類
- IGP(Interier Gateway Protocol)
- 自分が管理するLAN内部のルータ同士で経路情報を交換し合うプロトコル
- 規模別: 小規模 RIPv2, IGRP 中規模以上 OSPF, IS-IS, EIGRP
- RIPv2
- OSPF(Open Shortest Path First)
- EGP(Exterior Gateway Protocol)
- VLAN
- 「 VLAN(Virtual LAN)とは、スイッチ内を論理的に分割する機能」
- 上の前提として、L2スイッチにはデフォルトではVLAN1しかなく、すべてのポートがVLAN1のポートになっている(なので、すべてのポート間でイーサネットフレームの転送ができる)
- VLAN1しかなく = 1つのネットワークアドレスしかなく
- VLAN1つにローカルネットワークのネットワークアドレスを1つ割りふれる
- 1つの(物理的な)スイッチの中で複数のVLANをもてたりすると何が嬉しい?
- 物理的に機器を用意する制約が緩和
- ポートVLAN
- 1台のL2スイッチ中のポートをいくつかのVLANに割りふれる
- 複数台のネットワークアドレスのために複数台のスイッチがいる ... でもスイッチ買う予算なんて ... う...
- (1つ1つのVLANにつなぐぽーと数が少ない小規模なVLANなら)ポートVLANを使えば物理的なスイッチは1台でもいけるかも...?
- タグVLAN
- 1つのVLANがめっちゃでかくて、レイヤー2スイッチ1台だけでは扱えず、複数のレイヤー2スイッチを使いたい ... タグVLAN
- ダーティリード、ファジーリード、ファントムリードとは、トランザクションの隔離が不十分な場合に発生する可能性のある三つの異常な読み込み現象のことを指す
- SSL通信
- WEBブラウザからWEBサーバに対して安全に共通鍵を送付するために公開暗号方式を使う
- Java SEとJava EE
- ポートスキャン
- DoS攻撃とDDoS攻撃
- オープンリレー
- MTAが外部からアクセスできる状態だと、スパムメールの転送のために利用される(ふつうは自社ネットワーク内など信用できる送信元のみ転送するように設定)
mysql2のgemのインストール時にchecking for mysql_query() in -lmysqlclient... no が出ていたらC言語版のMySQLのクライアントライブラリがない
mysql2のgemをインストールするときに、
checking for mysql_query() in -lmysqlclient... no ...
のエラーが出て失敗する場合、C言語版のMySQLのクライアントライブラリがないです。
なので、たとえばMac OS X(10.11.6)の場合、
$ brew mysql
でC言語版のMySQLのクライアントライブラリ(コマンドでmysqlって入れたら動きだすやつ)を入れたらインストールを進めることができます。
Macの場合は、上記のようにHomebrewを使ったり、MacPorts, MySQLのインストーラを使ってインストールした場合パスの指定は不要となりますが、他のパスにすでにMySQLのクライアントが入っていてそちらを利用したい場合はオプションでそのパスを指定する必要があります。
--with-mysql-dir[=/path/to/mysqldir]MySQLのインストールされたパス*1--with-mysql-config[=/path/to/mysql_config]MySQLにはMySQLのコンパイル方法やMySQLのクライアントへの接続方法が入っている mysql_conf という設定ファイルがあって、そのパスを指定する
なお、上記の2つのオプションは一度にどちらかひとつしか使えません。
native extensionのgem苦手意識あって毎回この辺どたどたしてたんですが、めずらしくすっきりしたのでメモ!
