Alfred 3 のテーマ

先日、Alfred 3がリリースされた。パワーパックは2で購入していたので £12 でアップグレードできる。 とはいえ、2で満足できてたし1,600円払ってまでアップグレードするほどの目玉機能入ったの?? 早くなった?ワークフローが強くなった?いやー、2で十分でしょと思っていた。

でも、即アップグレードすることになった。

2で唯一困っていたことは「テーマのフォントが好きなフォントに変更できない」ということ。 不満に思っている人も多いらしく、海外の掲示板でもイロイロ議論されていた。

しかし、今回3ではこのフォント変更が可能になったことに加え、Blurエフェクトをつけることが可能になった。 この機能追加を見た途端、アップグレードするしかないと思い立ち £12 の支払いをPayPalにて完了した。

幾つかテーマを作って公開しようとしたが、公式(?)に投稿するテーマには制限があり「Standard Fonts」を使ったものしか投稿できない仕様になっているようだ(そんな気はしてた)。

To share themes on alfredapp.com, your theme needs to use fonts from the 'Standard Fonts' section in the font popup menu. These fonts will work in Alfred on every standard Mac configuration.

最終的にはGitHubにアップロードした。

作ったテーマは以下の3つ。

f:id:ringo6119:20161003001843p:plain

f:id:ringo6119:20161003001849p:plain

f:id:ringo6119:20161003001856p:plain

やっぱ、細いフォント綺麗だね。Retinaあってこそだけど。

よかったらどうぞ(Hiragino Sans 使ってます)。

沖縄の岩場 読谷ボルダーと瀬底ボルダー

ぼくは、趣味であるスキューバダイビングをするため、年に一度くらいのペースで沖縄に行く。 さらに、もう一つの趣味であるボルダリングもついでにやろうと思い登れる岩場を調査した。調べてみると、あまり多くの情報は無く(あっても古く)トポなどは存在しなかった。 沖縄のボルダーを登る人は少ないかもしれないが、探している人のためにメモを書いておこうと思う。今回は名護に滞在したため、読谷と瀬底ボルダーに行った(前回は具志頭に行った)。

トポについて

以前はコーラルロックというところでトポが販売されていた模様。「ぶり」(具志頭ボルダーのトポ)も「Coral on the beach 沖縄ボルダリング課題集」(沖縄本島のトポ)も販売していないようだ。

前回沖縄に訪れたときは、具志頭ボルダーに行ったときに地元のボルダーの方がトポ(ぶり)を持っていたので観せてくれて大変助かった。トポを持っていない状態ではYoutubeの動画を観ながらラインや岩を探すしかないのが現状。

少しでも参考になるように(自分で忘れないために)、場所だけメモしておく。 また、余裕があったら写真も撮ってきたので何処かにメモ用のトポをアップロードしようと思う。

トポ情報お待ちしております(切実)。

岩質

岩は琉球石灰岩という沖縄特有のもので、登ると凄い痛い。岩肌が鋭利なうえ、課題はバルジやルーフが多くとにかく痛い。テーピングが必須とされる。親指以外の指の腹に細いテーピングを巻きつけるとよい。膝とかをぶつけるとすぐ血が出るので注意。

読谷ボルダー

ホテル日航アリビラ」の隣(?)のビーチにある「アリビラボルダー」と、近くにある「体験王国むら咲むら」の「むら咲むらビーチ」の隣りにある「熟女岩」からなるボルダーで、今回はアリビラボルダーしか行けなかった。

最初は、それっぽい岩がありすぎて、どの岩が「それ」なのか全く分からず30分くらいマットを背負って浜辺を歩き回った。

f:id:ringo6119:20160929123113p:plain f:id:ringo6119:20160929123123p:plain

それっぽいのが見つかったのがこれ。おそらく右側がアリビラボルダーで、左側もなんだか少し登った形跡がある。

f:id:ringo6119:20160920143534j:plain

右側の岩は、写真右上のヤシの木(?)と、左下の三角形のように黒く飛び出している岩の形が特徴だと思う。あと、濡れてる。

f:id:ringo6119:20160920144518j:plain

下地は岩がむき出しだったが、平らだったのでブルーシートとマットを敷いた。 正直課題はどこになにがあるかよくわからなかったので、適当に登ってYoutubeにあった動画から「無名4級」を登った。他にも初段とか熟女岩の方も挑戦したかったが、この後名護まで行かなければならず、時間がなくて撤退。

f:id:ringo6119:20160929122931p:plain

地図はこんな感じ。

もっと、やりたかった。。。あと、トポがほしい。。

参考動画・サイト

瀬底ボルダー

ここもあまり情報は無かったので、Youtubeの動画をもとに岩を探してそれっぽいのを見つけた。この後、ヘリオス酒造の酒造見学があったので、滞在時間が30分しかなく悲しかった。酒造見学に行かずここで登っていたかったがドライバーがぼくしかいなかったので断念(そして、見学に行ってもドライバーなので飲めない)。

瀬底ビーチの駐車場(1,000円)に車を停め5分くらい浜辺を北に歩く。どれも登れそうで、時間があれば課題とか気にせず登ってみたかった。

こういうルーフとかがたくさんあった。

f:id:ringo6119:20160922091033j:plain

すると、動画に写っているっぽい岩が見つかった。写真右側の手前に写っている、ふたコブの岩がそうだと思う。水の流れたような黒い跡や、左奥に写っているヤシの木の生えた岩が目印。

f:id:ringo6119:20160922092033j:plain

ところが動画を見てみると、スタートはもっと下からしているようにみえる。どうやら砂で1mほど埋まってしまっている模様。仕方ないので出来るところからスタートして登れるところまで登った。動画も一つしか見つからず、時間もないのですぐ撤退。

地図はこんな感じ。

参考動画

まとめ

今回は、名護周辺のボルダーを回った。まだ、北側や東側のボルダーは行ったことがないので調査して行ってみたい。具志頭も行きたかったが真逆だったため断念。岩場の規模としては具志頭ボルダーが一番大きいようだ。

課題が設定されていない場所(そもそもトポがないからよくわからないが)じゃなくても登って楽しめる岩がたくさんあるのでまた行きたい。あとチョークは一応持っていったけど全く使わなかった。ゴミは残さないように。

最後に、沖縄ボルダリングマップを置いておきます。

参考文献

Terraform に入門してみる

Terraformを使うのでとりあえず入門記事を漁って見る。

とりあえず、 Terraform簡易チュートリアル on AWS - Qiita をハンズオンしてみる。

事前準備

AWS アクセスキーの発行

公式ドキュメントを参照(アクセスキー ID と秘密アクセスキーの取得 )して、アクセスキーとシークレットアクセスキーを発行する。

また、 aws-cli をインストールして aws configure を実行しておく。

Terraformのインストール

OSXなのでhomebrewを使ってインストール

brew update && brew install terraform

インストール出来た。

$ terraform -v
Terraform v0.6.14

Your version of Terraform is out of date! The latest version
is 0.6.15. You can update by downloading from www.terraform.io

AWSにEC2インスタンスを立ててみる

Terraform の設定ファイルを書く

「Terraform」の設定ファイルは「JSON」か「HCL」のどちらかで記述できる。 JSON の場合は *.tf.json 、 HCL の場合は *.tf という拡張子をつける。 HCL は「HashiCorp Configuration Language」の略で、設定ファイルを記述するために HashiCorp が独自に設計したシンタックスJSON と比較して可読性がよいらしい(いちいち{}でくくらなくてもよいのもメリット)。

とりあえず、 git init して書き始めよう。

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "hello-aws" {
  ami = "ami-a21529cc"
  instance_type = "t2.micro"
}

この、 provider とか resource をブロックを呼ぶらしい。

まず、 provider を記述する。今回は AWS に構築をしてみるので aws を指定指定する。 プロバイダの一覧は公式ドキュメント参照access_keysecret_keyaws configure で設定していない場合はここで記述する。 reagion には対象のリージョンを指定する(リージョンとアベイラビリティーゾーン)。東京は ap-northeast-1 なので、これを指定。

resource ブロックは引数を二つとり、第一引数に「作成するリソースのタイプ」を、第二引数に「リソース名」を指定する。プロバイダが AWS の場合に指定できるリソースは公式ドキュメント参照(AWS PROVIDER)。 とりあえずチュートリアルに習って、 EC2 のインスタンスを作成してみる。

リソースブロックの第一引数に aws_instance 、第二引数の名前に hello-aws を記述(AWS: aws_instance - Terraform by HashiCorp)。

ドキュメントをみると、この aws_instance には必須項目が二つある。

AMI はなんとなく ami-a21529ccUbuntu (無料枠の対象)を指定してみる。 インスタンスタイプは t2.nano が一番安いんだけど、無料枠の対象の t2.micro を指定。

インスタンスを起動する

plan で Dry Run してみる

terraform のサブコマンドに plan というのがある。このコマンドを実行することにより、どのような変更が適用されるか事前に確認することができる。

terraform plan
Refreshing Terraform state prior to plan...


The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

+ aws_instance.hello-aws
    ami:                      "" => "ami-a21529cc"
    availability_zone:        "" => "<computed>"
    ebs_block_device.#:       "" => "<computed>"
    ephemeral_block_device.#: "" => "<computed>"
    instance_state:           "" => "<computed>"
    instance_type:            "" => "t2.micro"
    key_name:                 "" => "<computed>"
    placement_group:          "" => "<computed>"
    private_dns:              "" => "<computed>"
    private_ip:               "" => "<computed>"
    public_dns:               "" => "<computed>"
    public_ip:                "" => "<computed>"
    root_block_device.#:      "" => "<computed>"
    security_groups.#:        "" => "<computed>"
    source_dest_check:        "" => "1"
    subnet_id:                "" => "<computed>"
    tenancy:                  "" => "<computed>"
    vpc_security_group_ids.#: "" => "<computed>"


Plan: 1 to add, 0 to change, 0 to destroy.

Note が表示された。

Note: You didn’t specify an “-out” parameter to save this plan, so when “apply” is called, Terraform can’t guarantee this is what will execute.

これは、「 out パラメータを指定してプランを保存しなかったら、 apply 呼ばれた時に何を実行するか保証できないよ!」ってことだと思う。多分、 plan した後に別の人が別のところで apply した場合は、今回行った plan は意味なくなるから気をつけろよってことだと思う。

あとで、実験しよう。

あと、 terraform.tfstate というファイルが作成される。これは、 Terraform が管理しているリソースを JSON で保存しておくファイルらしい。 いまは、何も適用してないから空っぽいファイルができてるね。

{
    "version": 1,
    "serial": 0,
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {}
        }
    ]
}

apply で適用する

apply のサブコマンドを実行すると、 *.tf ファイルの記述に従って処理が適用される。

$ terraform apply
aws_instance.hello-aws: Creating...
  ami:                      "" => "ami-a21529cc"
  availability_zone:        "" => "<computed>"
  ebs_block_device.#:       "" => "<computed>"
  ephemeral_block_device.#: "" => "<computed>"
  instance_state:           "" => "<computed>"
  instance_type:            "" => "t2.micro"
  key_name:                 "" => "<computed>"
  placement_group:          "" => "<computed>"
  private_dns:              "" => "<computed>"
  private_ip:               "" => "<computed>"
  public_dns:               "" => "<computed>"
  public_ip:                "" => "<computed>"
  root_block_device.#:      "" => "<computed>"
  security_groups.#:        "" => "<computed>"
  source_dest_check:        "" => "1"
  subnet_id:                "" => "<computed>"
  tenancy:                  "" => "<computed>"
  vpc_security_group_ids.#: "" => "<computed>"
aws_instance.hello-aws: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate

作成されたっぽい。 computed の部分は特になにも指定してないので動的に作成される(っぽい)。 インスタンスの詳細を見るには show を使えって書いてあるので実行してみる。

$ terraform show
aws_instance.hello-aws:
  id = i-4a10aed5
  ami = ami-a21529cc
  availability_zone = ap-northeast-1a
  ebs_block_device.# = 0
  ebs_optimized = false
  ephemeral_block_device.# = 0
  iam_instance_profile =
  instance_state = running
  instance_type = t2.micro
  key_name =
  monitoring = false
  private_dns = ip-172-31-4-134.ap-northeast-1.compute.internal
  private_ip = 172.31.4.134
  public_dns = ec2-52-192-1-94.ap-northeast-1.compute.amazonaws.com
  public_ip = 52.192.1.94
  root_block_device.# = 1
  root_block_device.0.delete_on_termination = true
  root_block_device.0.iops = 24
  root_block_device.0.volume_size = 8
  root_block_device.0.volume_type = gp2
  security_groups.# = 0
  source_dest_check = true
  subnet_id = subnet-8b78affc
  tags.# = 0
  tenancy = default
  vpc_security_group_ids.# = 1
  vpc_security_group_ids.1967208828 = sg-9257fef7

なんかイロイロ表示されましたね。 ちゃんと起動してるかチェック。

$ aws ec2 describe-instances --instance-ids "i-4a10aed5" | jq '.Reservations[].Instances[] | {"Image ID": .ImageId, "Instance ID": .InstanceId, "Status": .State.Name}'
{
  "Image ID": "ami-a21529cc",
  "Instance ID": "i-4a10aed5",
  "Status": "running"
}

起動してるっぽい。

インスタンスを変更する

ためにしに、 AMI を Ubuntu から Amazon Linux に変更してみる。

diff --git hello-aws.tf hello-aws.tf
index cbe294a..62aeca0 100644
--- hello-aws.tf
+++ hello-aws.tf
@@ -3,6 +3,6 @@ provider "aws" {
 }

 resource "aws_instance" "hello-aws" {
-  ami = "ami-a21529cc"
+  ami = "ami-f80e0596"
   instance_type = "t2.micro"
 }

terraform plan を実行。

Refreshing Terraform state prior to plan...

aws_instance.hello-aws: Refreshing state... (ID: i-4a10aed5)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

-/+ aws_instance.hello-aws
    ami:                      "ami-a21529cc" => "ami-f80e0596" (forces new resource)
    availability_zone:        "ap-northeast-1a" => "<computed>"
    ebs_block_device.#:       "0" => "<computed>"
    ephemeral_block_device.#: "0" => "<computed>"
    instance_state:           "running" => "<computed>"
    instance_type:            "t2.micro" => "t2.micro"
    key_name:                 "" => "<computed>"
    placement_group:          "" => "<computed>"
    private_dns:              "ip-172-31-4-134.ap-northeast-1.compute.internal" => "<computed>"
    private_ip:               "172.31.4.134" => "<computed>"
    public_dns:               "ec2-52-192-1-94.ap-northeast-1.compute.amazonaws.com" => "<computed>"
    public_ip:                "52.192.1.94" => "<computed>"
    root_block_device.#:      "1" => "<computed>"
    security_groups.#:        "0" => "<computed>"
    source_dest_check:        "true" => "1"
    subnet_id:                "subnet-8b78affc" => "<computed>"
    tenancy:                  "default" => "<computed>"
    vpc_security_group_ids.#: "1" => "<computed>"


Plan: 1 to add, 0 to change, 1 to destroy.

新しいリソースを作るみたいな表示になってる。

ami: "ami-a21529cc" => "ami-f80e0596" (forces new resource) Plan: 1 to add, 0 to change, 1 to destroy.

terraform apply を実行。

aws_instance.hello-aws: Refreshing state... (ID: i-4a10aed5)
aws_instance.hello-aws: Destroying...
aws_instance.hello-aws: Destruction complete
aws_instance.hello-aws: Creating...
  ami:                      "" => "ami-f80e0596"
  availability_zone:        "" => "<computed>"
  ebs_block_device.#:       "" => "<computed>"
  ephemeral_block_device.#: "" => "<computed>"
  instance_state:           "" => "<computed>"
  instance_type:            "" => "t2.micro"
  key_name:                 "" => "<computed>"
  placement_group:          "" => "<computed>"
  private_dns:              "" => "<computed>"
  private_ip:               "" => "<computed>"
  public_dns:               "" => "<computed>"
  public_ip:                "" => "<computed>"
  root_block_device.#:      "" => "<computed>"
  security_groups.#:        "" => "<computed>"
  source_dest_check:        "" => "1"
  subnet_id:                "" => "<computed>"
  tenancy:                  "" => "<computed>"
  vpc_security_group_ids.#: "" => "<computed>"
aws_instance.hello-aws: Creation complete

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate

確認してみる。

$ terraform show | grep " id ="
  id = i-1cd06883
$ aws ec2 describe-instances --instance-ids "i-4a10aed5" "i-1cd06883" | jq '.Reservations[].Instances[] | {"Image ID": .ImageId, "Instance ID": .InstanceId, "Status": .State.Name}'
{
  "Image ID": "ami-a21529cc",
  "Instance ID": "i-4a10aed5",
  "Status": "terminated"
}
{
  "Image ID": "ami-f80e0596",
  "Instance ID": "i-1cd06883",
  "Status": "running"
}

古い方は terminated になってるし、新しい方は違う AMI ID で running になってる。

インスタンスの削除

インスタンスの削除は plan-destroy オプションをつけてプランファイルを作成し、 apply 実行時にプランファイルを指定して実行する。

プランファイルを作成して。

$ terraform plan -destroy -out=destroy.tfplan
efreshing Terraform state prior to plan...

aws_instance.hello-aws: Refreshing state... (ID: i-1cd06883)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

Path: destroy.tfplan

- aws_instance.hello-aws


Plan: 0 to add, 0 to change, 1 to destroy.

削除。

$ terraform apply ./destroy.tfplan
aws_instance.hello-aws: Destroying...
aws_instance.hello-aws: Destruction complete

Apply complete! Resources: 0 added, 0 changed, 1 destroyed.

確認してみると両方とも terminated になってた。

$ aws ec2 describe-instances --instance-ids "i-4a10aed5" "i-1cd06883" | jq '.Reservations[].Instances[] | {"Image ID": .ImageId, "Instance ID": .InstanceId, "Status": .State.Name}'
{
  "Image ID": "ami-a21529cc",
  "Instance ID": "i-4a10aed5",
  "Status": "terminated"
}
{
  "Image ID": "ami-f80e0596",
  "Instance ID": "i-1cd06883",
  "Status": "terminated"
}

References

Amazon Fire TV Stick のリモコンを忘れた話

正月は実家に帰ってAmazon Fire TV Stick 海外ドラマ見てダラダラ過ごす他ほかないと計画し、TV Stick を忘れずにカバンに入れて安心しきっていた。いざ、ゴロゴロしようと思ったらリモコンを忘れていたことに気づいた*1

色々調べてみると、BRAVIA とかだとテレビのリモコンがそのまま使えるって書いてあったので、家にあった REGZA 37H3100 で試してみたが全然反応しなかった。もう一個小さいテレビ(REGZA 19A2)があったので、それで試すとちゃんとTVのリモコンでも反応して大勝利だった。

そいつでWi-Fiを設定したら、あとは、iPhoneAmazon Fire TV Remote を認証してiPhoneから操作することができた。

リモコンを忘れてもなんとかなるという知見が得られて非常によかった。 でも、やっぱりリモコンのほうがいいね。アプリめっちゃ操作し辛い。

References

*1:もちろんArduinoも忘れた

dockerがVPNのせいで繋がらなくなった時は面倒くさい

VPNとか繋いだりすると、詳しいことはよくわからないがdockerコマンドが返ってこないことがよくある。

そういう時は、次のコマンドを打つと直る。

boot2docker down
sudo route -nv delete -net 192.168.59 -interface vboxnet1
sudo route -nv add -net 192.168.59 -interface vboxnet1
boot2docker up

それも面倒くさいので、.zshrcに以下の様なエイリアスを付けてやると楽。

alias redock="boot2docker down && sudo route -nv delete -net 192.168.59 -interface vboxnet1 && sudo route -nv add -net 192.168.59 -interface vboxnet1 && boot2docker up"

redock を打つだけで再起動できる。

References