そうだ金閣寺に行こう
先週末は大阪に行っていて、そのついでに金曜から土曜は京都に滞在していました。 前職ではよく京都に行くことがあったのですが、いつでも行けると意外と行かないということで、まともに観光したことは一度しかなく、それ以外は普通に買い物をしてたりしていたのです。
とはいえ、今回は何も予定を決めていなかったのですが、晴天に恵まれ、ホテルをチェックアウトで追い出されて、四条あたりを巡っていたのですが、いまいちだなーということで、行ったことのない金閣寺に足を伸ばしてみました。
続きを読む目もとエステ<リフレタイプ> EH-SW52
昔からずっとパソコンやらスマホやら触っていることには変わりないのですが、年齢的なものか、慢性的に目が疲れていて、視力も下がりつつあるこの頃。
気になっていたPanasonicの目もとエステを購入していたのでメモ。
バイブレーションするのがよい
基本的な動作としては、ほのかに暖かくなりつつ、電動で振動する点。 蒸気でホットアイマスクなどと比較して大きく違う点は、この振動する点です。 ただ、そんなに振動するわけでもないし、12分で停止するのはちょっと短い。
すぐに温まらないです。ホットアイマスクと異なり、直接温熱部分と肌が接触しないので、その部分の違いが大きいかと。それヘッドマウントディスプレイでもいいんじゃない感。
スチームは難あり
スチームについては、細かい穴が開いたプレートみたいなのを水に濡らしてセットし、あとは、本体の発熱にまかせて自然蒸発する感じになっています。 毎回利用直前に濡らしてあげる必要があるので、ちょっとめんどいです。
まとめ
個人的には、蒸気でホットアイマスク的なものがイマイチで、こちらのがよいですが、効果があるかというと難しいところ。レビューにある通り、ホットアイマスクのがいいという人もいるので、個人差があると思います。
あとは、価格がちょっと高いかもなぁ。
Panasonic 目もとエステ リフレタイプ グレー EH-SW52-H
- 出版社/メーカー: パナソニック
- 発売日: 2013/09/01
- メディア: ホーム&キッチン
- この商品を含むブログを見る
押しやすいドメインを探す
短くて覚えやすいドメインは取得されてしまっていることが多いです。とはいえ、jpドメインだと3文字が割と残っているので、ここから「キーボードで押しやすい」ドメインを探してみるスクリプトをリハビリがてら書いてみた。 これは、ガラケー時代のケータイ配列で押しやすいと同じ感じで、意味をこじつけるなどして覚えてもらえば、十分価値のあるドメインになると思います。
押しやすい定義
以下の定義を考えましたが、今回は一番上の配置が近い文字のみを見ています。
- QWERTYキーボードにおいて、キー配置が近い文字は押しやすい
- 文字数が小さいほど押しやすい
- 左手と右手を両方使いたくなる配列はよくない
- 誤認しやすい文字はあまりよくない (0 and o, 1 and l)
セキュリティグループをつくるいろいろ
アカウントを新しく使いはじめる場合や、新しいサブネットを作成したときに、ベースのセキュリティグループをとりあえずセットアップしたいパターンはよくあると思う。 とりあえず、ログインするために、会社のIPからのアクセスを許可するとか。
以下のシナリオを考えてみる。
- ELB + WEBサーバ (EC2)+ DB (RDS) の構成
- Public Subnet, Private Subnetを定義
- 会社のIPからのSSHアクセスを許可する
これを元に以下の構成を考える。
NATインスタンスがいないとか、いろいろあるけど、今回のテーマではないので割愛。
aws cliコマンドライン
まず空のセキュリティグループを作成して、そこにルールを追加する形になる。
- aws ec2 create-security-group コマンドを叩いてセキュリティグループを作成。セキュリティグループIDを取得。
- aws ec2 authorize-security-group-ingressコマンドでIngressのルールを追加
コマンド実行の戻りを変数に入れて、というのがシェルスクリプトだとちょっと面倒です。楽しようと、上では--queryでGroupIdのみ取得していますが、エラーが起きた時のハンドリングができていません。
セキュリティグループを参照したり、変数の嵐となってつらいので上では1個だけ作成しています。
スクリプト (botoの場合)
セキュリティグループをルールに含めたセキュリティグループをつくるのはスクリプト楽ですね。
botoのboto.ec2.securitygroupは、ingress (inbound)前提となっていて、egress (outbound)も使う場合は、
ec2.connectionのauthorize_security_group、authorize_security_group_egressあたりを利用することになると思います。
他の各言語のAWS SDKなどでも、Create Security Groupして、そこに対してルールを追加する同様の感じとなります。
- AWS SDK for PHP: authorizeSecurityGroupIngress, createSecurityGroup
- AWS SDK for Ruby: Class: AWS::EC2::SecurityGroup — AWS SDK for Ruby
- AWK SDK for Java: createSecurityGroup
CloudFormation
CloudFormerで作成した例。CloudFormerについてはクラスメソッドさんのブログが分かり易い。
上のようなJSONを生成して、例えばAWS CLIでキックする。
aws cloudformation create-stack --stack-name generate-security-group --template-body file://generate-securitygroup.json
このJSONでは、VPC IDが決め打ちになっているが、もちろんVPC自体も作成できる。
問題点としては、リソース名 (Security Group Name)が、CloudFormationによる自動生成となること。タグで代替できるが、タグは重複を許容するのが、場合によってはあんまりよろしくない。 あと、CloudFormationスタックにセキュリティグループが紐付いているので、スタックを削除すると削除しちゃうので、適宜、Stack Policyを設定する。
まとめ
実際に運用する場合には、VPCと組み合わせて、
- Public Subnet、Private Subnetを定義し、NATインスタンスを起動させる
- 会社側のIP制限ルールのため、踏み台インスタンスを用意してElastic IPを付与したい
とかいろいろあると思う。
こうなってくると、登場人物が増えてくるのと、案件によって変わってきたりして、ちゃんとがっちり構築しようとすると厳しかったりするが、できるところから、ルールが決まっている部分について自動化しておくと、完全な自動構築までの道のりもクリアになる。
