KickstarterでサポートしていたRoost Laptop Standが届いた

届いた!

www.kickstarter.com

出資から届くまで

Roostの存在をRebuildで知る

rebuild.fm

おお、2014/10。。。

2015/05 ふとポチる

Kickstarter経由でRoostから経過報告をもらう

大体1ヶ月に1〜2回メールが届いていました。

途中に送付先住所の登録とか、別の商品の紹介とかもありました。

で、その瞬間だけ思い出して、メールを眺めて、あとは忘れていました。

2015/12/30 Roostから出荷の連絡が

DHL Expressという配達会社経由で送付したのこと、出荷追跡もできるようになっていました。

ここから楽しみになってきました。

無事受け取り

ずっと、不在通知がきている状況でしたが、なんとか今日受け取ることができました!

届くまで結構長かったので、予想外のプレゼントみたいでうれしい。

開けてみて

f:id:k1LoW:20160109151207j:plain

意外に小さめ。専用ポーチ付き。

f:id:k1LoW:20160109210004j:plain

15inchもしっかりホールドできています。ホールドする部分のギミックがとても良い

f:id:k1LoW:20160109210109j:plain

軽い。丈夫そうですが、とりあえずこれから使ってみてみようと思います。

AWSのCloudWatchのメトリクスをCLIからカジュアルに確認したいと思ってツールを作り始めている

asciicast

やりたいこと

  • 何か問題が発生した時に、手元のターミナルでAWSリソースの状況をカジュアルに確認したい
    • 初動を早くしたい
    • プロジェクトが多すぎて「ディスプレイで常に見える化」みたいなのは無理

現状

  • インスタンスIDとかRDSのIDを指定したらCloudWatchのメトリクス情報を *stat ライクに表示する
  • YAMLファイルでCloudWatchで取得するメトリクス情報を実質的にいくらでも拡張可能(YAMLファイルでオプションを拡張する実装)

ちなみにデフォルトのYAMLファイルは以下のような感じ。

---
resources:
  ec2:
    namespace: AWS/EC2
    dimensions_name: InstanceId
    metrics:
      cpu:
        metric_name: CPUUtilization
        statistic: Average
      netin:
        metric_name: NetworkIn
        statistic: Average
      netout:
        metric_name: NetworkOut
        statistic: Average
  rds:
    namespace: AWS/RDS
    dimensions_name: DBInstanceIdentifier
    metrics:
      cpu:
        metric_name: CPUUtilization
        statistic: Average
      read:
        metric_name: ReadIOPS
        statistic: Average
      write:
        metric_name: WriteIOPS
        statistic: Average
  elb:
    namespace: AWS/ELB
    dimensions_name: LoadBalancerName
    metrics:
      req:
        metric_name: RequestCount
        statistic: Sum
      400:
        metric_name: HTTPCode_Backend_4XX
        statistic: Sum
      500:
        metric_name: HTTPCode_Backend_5XX
        statistic: Sum

TODO / 検討事項

  • *stat ライクに定期間隔で追記出力(最短で1分間隔だけど。。。)
  • どれくらい行を出すかの設定(時間?最大行?)
  • CloudWatchアラームの状態で数値の色を変える?それともYAMLで設定?
  • テーブル表示がちょっと冗長なのでなんとかしたい。現在は tj/terminal-table · GitHub を利用
  • awstat という名前で作っているけれどもAWStatsとレーベンシュタイン距離が1

git-gsubがライフチェンジングだったのでgit-gsub-filesを作った

Gitで何かの仕方を検索していて、いまさらながら git-gsub を知りました。

fujimura.hatenablog.com

gemとして公開されており、カジュアルにインストールできてめちゃくちゃ便利です。

となると気になるのが git-rename 。おそらく想像するにファイル名の便利置換コマンド。ファイル名の置換もよくあるので、こちらも是非使いたいなと思いました。

が、gemとして公開されていなかったので、git-gsub を参考に git-gsub-files を作ってみました。

github.com

簡単にいうと、Gitで管理されているファイルのリネーム( mv )を gsub ライクにするためのGitサブコマンドです。

インストール

$ git install git-gsub-files

使い方

Gitの管理下のファイルに対して、ファイル名をgsubライクに置換して mv します。 置換対象はファイル名だけでディレクトリ名には影響しません。

$ git gsub-files READ WRITE
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

deleted:    README.md

Untracked files:
(use "git add <file>..." to include in what will be committed)

WRITEME.md

no changes added to commit (use "git add" and/or "git commit -a")

せっかくGitなので、mv ではなくて git mv したいこともあります。そのときは --add オプションを使います。

$ git gsub-files READ WRITE --add
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed:    README.md -> WRITEME.md

no changes added to commit (use "git add" and/or "git commit -a")

と、ここまで作って本家が公開されていました。。。

想像していた動きとは少し違っていたので、まあgit-gsub-filesを作った意味はあったかもです。

Thor人間だったのに、Thor使わないでコマンド作ったり、Rspecの書き方を git-gsub のテストを見ながら学んだり、俺得でした。

最後に

git-gsubという便利コマンドを公開してくださった fujimura さんありがとうございます!

最近のawspec活動 その2

v0.27.1になりました


Evolution of awspec (Gource Visualization)

リソースタイプを増やした

現在23個になっています。もう少し増やしたい。けどユースケースを考えながら追加するので、なかなか増えない。。。

AWS Advent Calendar 2015に参加した

qiita.com

awspec generate という便利コマンドの実践的紹介です。

Fukuoka.rbの成果をリリースした

具体的な成果

実際に何を追加したかというと、aws-sdk-rubyAws::Resources::Resource を継承している Aws::EC2::Instance などを its() {} などで呼び出せるようにしました。

これが追加されたことで、aws-sdk-ruby を知っていれば、awspecでマッチャーが作られていないような細かい箇所についてのテストが書けるようになります。

例えばこんな感じで、

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq 'my-bucket-owner' }
end

describe vpc('my-vpc') do
  its('instances.count') { should eq 3 }
end

ただ、そのままだと

describe vpc('my-vpc') do
  its('instances.batch_terminate!') { should eq '' }
end

とかで、「テスティングフレームワークなのに、なぜか対象リソースを潰してしまう」という狂気が実行できてしまうので、 Awspec::ResourceReaderAws::Resources::Resource なオブジェクトをラップして雑なブラックリストで判定しています。(まだ抜けはありそう)

最初はホワイトリストを検討したのですが、あまりに列挙すべきメソッドが多く、また規則性がなかったので、 @udzura さんと話して、「(まあ)ブラックリストで」という感じで実装しています。

このアドバンスドな機能は、こちら の "Advanced use" の項目があるリソースタイプで利用可能です。

ロゴを作った

f:id:k1LoW:20151217231631p:plain

自分で描いたらこんな感じになりました。

今後

実務でもどんどん投入されているので、地道に開発継続していきます。

Fukuoka.rbでエクストリームフィッシュボールをして、エクストリームな体験をした #fukuokarb

成果です。

github.com

ひょんなことから @udzuraさんとペアプロをする機会を得たのですが、成果は出るわ勉強になるわで最高体験でした。教えてもらうことが久しぶりで新鮮過ぎて

な感じでした。

awspecに追加された強力な実装についてはまたいつか紹介するとして、とりあえずいろいろメモを記録。

あ、

メタプロRuby早く読んだほうがいい」と10回以上言われました。

まずは実装の方針について検討・共有

いきなりソースコードに向かうと思ったらそうではなかったです。

2時間のうち、1時間くらいは設計の話だったような気がします。SDKのドキュメントと、awspecのソースを表示しつつ、方針を決めました。

で、決まった今回の実装方針はこちら。

f:id:k1LoW:20151211185231p:plain

とてもわかりやすい!

特に緑でウニョウニョしている部分( ResponceReader )が今回の実装のポイントです!(本人たちは議論しながらなのでばっちり)

respond_to がわからないなんてちょっと。。。」

respond_to がぱっとでてきませんでした。これがレベル低いのかどうかすらわからないレベル。ちょっと能力差がありすぎました。 (ちなみに使っていました。。。)

Rubyに馴染んでいないのがまるわかり。

「メモ化してください」「え?」

def resource
  @resource ||= Awspec::ResourceReader.new(Aws::S3::Bucket.new(@id))
end

||= の部分ですね。まず「メモ化」の言葉の意味が出てこなかった(そういう言葉があるのは知っていた)です。

その後、説明をしてもらうとすんなり理解。シングルトンとの違いもすっきり。

テストは実装方針にしたがって順番に

今回は最終的に

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq 'my-bucket-owner' }
end

のテストが通れば完成なので、自分はついつい上のテストが通ることを急ぎがちなのですが、 @udzuraさんはしっかりと、「順を追って」「まずは」といいながら

describe s3_bucket('my-bucket') do
  its(:real_resource) { should be_an_instance_of(Awspec::ResourceReader) } # まずは直接アクセスしてインスタンスを確認
  its('real_resource.name') { should eq 'my-bucket' } # アトリビュートがStringの場合
  its('real_resource.acl') { should be_an_instance_of(Awspec::ResourceReader) } # アトリビュートがAws::Resources::Resourceの場合
  it 'should be a Exception when black list method is called' do # ブラックリストなメソッドを呼んだ場合
    expect { subject.delete }.to raise_error(
      Awspec::BlackListForwardable::CalledMethodInBlackList,
      'Method call :delete is black-listed'
    )
  end
  its(:acl) { should be_an_kind_of(Awspec::ResourceReader) } # 最終形態でのアクセス方法でインスタンスを確認
end

と、実装を進めながら順にテストを追加していきました。

今回は特に基盤となる部分の機能追加でもあるので、「あーね!あーね!」と言いながら関心していたら「博多..」と言われました。

正しい値を知るために、テストREDの結果を利用する

自分はstubの値を知っているので、

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq 'my-bucket-owner' }
end

とすぐ書いてしまうのですが、そこをあえて

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq '' }
end

と書いて、一旦テスト結果をREDにし、さらにテスト結果から my-bucket-owner というstubの値を知るということをしていました。

というかテストを書くとき、必ず結果をREDにするところからスタートしているのが、慣れているなーと思いました。 (ちょっとだけTDD?)

bin/console bin/setup と exe/ ディレクトリ とpry

@udzura さんに「あれ?」と言われて知った事実。

github.com

ちなみに bundle gem で生成されたのは覚えているのですが「なんだこれ、知らんわ」と消していました。。。

あと「pryがないなんて耐えられないんで。。。」とpryが追加されました。

対話インターフェースで確認する習慣がないです。。。どうやったらそういう習慣になるんだろう。

こちら修正しました

感想

  • 教えてもらうのがめちゃくちゃ楽しい。最高体験。
  • Ruby力足りない。でもそれが楽しい。最高体験。
  • 他の人のコーディングを見るだけで勉強になる。最高体験。
  • Emacs。最高。

また、是非やりたいです!

そんな豪華な体験ができる勉強会がFukuoka.rbです。みんなも来たほうが良いと思いました。

以上成果報告でした!

Fukuoka.rbでawspecを対象にペアプロをしてもらえることになったので、やりたいことを書いておく #fukuokarb

SlackのチャンネルでRubyの質問(というか悩みを相談)をしていたら、緊張ヤバいことにありがたいことに今日のFukuoka.rbで @udzura さんとペアプロをすることになりました。

もともとは自分の疑問をSlackチャンネルでうまく伝えられなかったことが発端だったので、先にやりたいことを書いておこうと思います。日本語がダメで伝わらないかもしれませんが。。。

やりたいことその1: awspec でテストできる範囲を劇的に増やしたい

もともとのアイデアはこちら↓

awspecでテストできる内容はaws-sdk-rubyを素で使ったテストよりも(当然)少ないです。

しかし、↑のアイデアをうまく実装できれば、awspec(のits() {} )で、(aws-sdk-rubyを理解していれば)かなり柔軟に多くの範囲のテストができるようになります。しかも、awspecの見た目のシンプルさはそのまま。

ところが、↑を単純に実装すると、

となるので、うまく解決して実装したいです。

やりたいことその2: リファクタリングをして lib/awpec/helper/finder/ の中をすっきりしたい

awspec/lib/awspec/helper/finder at master · k1LoW/awspec · GitHub

こんなものなのかどうかわからず。。。

やりたいことその3: 何かナレッジを

得られるようにがんばります!

緊張ヤバい…init.el整理したい…

aws-sdk-rubyで `*.example.com` なレコードを取得すると `\052.example.com` になる

某プロジェクトで awspec generate route53 example.com. を実行したのですが、なぜか

describe route53_hosted_zone('example.com.') do
  it { should have_record_set('\052.example.com.').cname('example.com') }
end

なspecが生成されて、「\052???」と調べ始めたのが最初。

端的にいうと、aws-sdk-ruby*.example.com なレコードを、Aws::Route53::Client#list_resource_record_setsで取得すると \052.example.com な文字列になる状況です。

で、@udzura さんと @nagachika さんという豪華布陣にも見てもらいつつ調べた結果が、

AWSAPIのレスポンス自体が\052.example.comになっているかも

という残念なことに。。。

AWS CLIでも

$ aws route53 list-resource-record-sets --hosted-zone-id AB1234CDEFGHIJ --profile xxx

...
{
    "ResourceRecords": [
        {
            "Value": "example.com"
        }
    ],
    "Type": "CNAME",
    "Name": "\\052.example.com.",
    "TTL": 300
 },
...

という。。。

というわけで

対応しました

route53_hosted_zone support `*` and `\052` as wildcard record by k1LoW · Pull Request #76 · k1LoW/awspec · GitHub

Fix wildcard record format when `terraforming r53r` by k1LoW · Pull Request #139 · dtan4/terraforming · GitHub

こちらで直接お礼を言おうと思います

fukuokarb.doorkeeper.jp