DSC_4302

Kaizen Platform, Inc. (現株式会社Kaizen Platform)を退職したときに、記念品として AeroPress をプレゼントしてもらった。この AeroPress がなかなかよくて気に入っているので紹介します。

AeroPress は Rebuild でも話題に上がったことがあるし、名前だけは知ってる人いるかもしれない。

自分はどういうわけか知らないけど存在を知っていた。おそらくスーパーウルトラ富裕なコーヒー好きの元同僚 @t32k さんのツイッターかブログで知ったのだろう。買いたいとは思っていたけど自分で買うには結構高くて躊躇していたところ、退職イベントが発生してプレゼントしてもらうことができた。カプ社の皆様ご恵贈ありがとうございました。

何がよいのか

味にぶれがないことがよい。ドリップでうまい味を再現するためにはお湯の量とか抽出時間とか一度に注ぐお湯の量とか気をつけなければならないことが多すぎると思う。 AeroPress を使う場合、豆の量とお湯の温度さえ気をつければよくて、あとはテキトーにやっても味が変わらない。毎回おいしくできるのがよい。

まずい豆でもそこそこおいしくなるのも不思議だけどよい。やっぱりコーヒーは豆の焙煎具合や鮮度が一番重要なファクターで、どんだけドリップを名人がやっても程度の低いコーヒー豆でおいしいコーヒーを抽出することは無理だと思う。 AeroPress を使ったとしてもその原則は崩れないのだけど、それでもスーパーの半額セールで買ったようなやつ(ドリップで飲むと思わず顔をしかめたくなるような味)でも「うん、まぁいけるね」という程度の味にはリカバリできる。本当に不思議。

さっと抽出できて片付けが楽なのもよい。ドリップは 3 分間くらい、ドリッパーの前につきっきりになってちょぼちょぼとドリップしていかなければならない。 AeroPress の場合、挽いた豆を容器の中に入れてお湯を注ぎ、付属のかき混ぜへらで混ぜてあとはカップの上に載せて抽出していくだけ。 30 秒くらいでできてしまう。片付けも楽で、プラスチックフィルターを外してぽんと押し出すだけで豆かすが捨てられる。洗うのもささっと流せば完了。めっちゃ楽。

オフィシャルな使い方

販売元的には AeroPress は空気で圧力をかけるエスプレッソみたいな存在なのだと思う。公式ページに置いてある動画でも少量を抽出して、お湯で薄める様子が紹介されている。

About the AeroPress coffee maker: Information, instructions, and videos

ただ自分的にはこの使い方はあまり合わなかった。コーヒー豆を沢山使わないとちょうどよい濃さのコーヒーにならない。自分は守銭奴なのでコーヒーを入れるときに使う豆の量はコップ一杯あたり 10g から豪遊しても 12g 程度に抑えたいと思ってる。 AeroPress 付属の計量スプーンは 15g 用で、一杯あたりのコーヒーにこんなに量を使えるのは @t32k さんのような富裕層だけだと思う。自分には無理。

いろいろやって試してみて、以下の入れ方が 10g のコーヒー豆で外れなしの抽出をできるという結論にたどり着いた。倒立法という逆さまにした方法で入れます。

自分の使い方

  1. コーヒー豆を挽いてお湯を沸かす
  2. 器具を組み立てて、本体の中に豆を入れる
    DSC_4305 DSC_4306 DSC_4308
  3. 沸かしておいたお湯を注ぐ。温度は 80 度にする。
    DSC_4309 DSC_4310
  4. ちょびっとだけ入れた状態でかき混ぜる
    DSC_4311
  5. お湯をぐーっと上まで注ぐ
  6. 付属のプラスチックフィルターに円形ペーパーフィルターをセットして本体にくっつける
    DSC_4312 DSC_4313 DSC_4314
  7. ぐいっと本体をひっくり返してマグカップの上にセットする
    DSC_4315
  8. 注射をするようにじわじわ最後まで押し込んでいく
    DSC_4316 DSC_4319
  9. できあがり
    DSC_4320
  10. 片付けも楽勝です。プラスチックフィルターを外して豆かすをゴミ箱に押しだし捨てるだけ
    DSC_4321 DSC_4322
  11. 飲みましょう
    DSC_4323

この入れ方だと一度に一人分しか抽出できない。 ArroPress は 4 人分まで抽出できるようになっているが、お湯で薄めることが前提となっている。上述の通りそれは豆の量が沢山必要になるので自分的にはこの入れ方に落ち着いている。

というわけで AeroPress: The Good Parts でした。コーヒー好きだけどなかなか自分ではおいしく入れられないという人は是非お試し下さい。


この記事は コーヒー Advent Calendar 2017 - Adventar 二日目の記事でした。明日は euxn23 さんです。

Rails 5.1 から入った Encrypted Secrets というのがある。 OAuth の client_secret などパスワード的なやつを暗号化して保存する仕組み。この手のやつはこれまで環境変数などにして dotenv などの機能を使ってそれぞれの環境ごとに .env ファイルを置く、というのがベストプラクティスだったと思うけど、 Encrypted Secrets を使えば秘密情報も暗号化してリポリトリに放りこめるので管理対象が少なくなって便利になる。暗号化するときの鍵は RAILS_MASTER_KEY という環境変数に格納するか、 gitignore した上で config/secrets.yml.key という名前で配置すると Rails がいい感じに読み取ってくれる。

Rails のエコシステムには config (旧 rails_config )という gem もあって、こいつも設定系の情報を入れておく用途によく使う。秘密系の情報と設定系の情報でどちらに値が入っているかを意識するのがめんどい& Rails.application.secrets.foo_bar とか入力するのが長い& Encrypted Secrets は YAML をネストさせられないのがだるいので、 config.gem の config/settings.yml の中で以下のようにしたら便利ではないかと思ってやってみた。

foo:
  bar: <%= Rails.application.secrets.foo_bar %>

呼び出し側の before after はこんな感じ。

Before

bar = Rails.application.secrets.foo_bar

After

bar = Settings.foo.bar

「めっちゃ最高便利じゃん」と思っていたけど、これをやると副作用がでかい。なんと Rails.application.secretsfoo_bar が見つからなくなる! というか Rails.application.secrets がほぼほぼ空になる!!!、!

[3] pry(main)> Rails.application.secrets
=> {:secret_key_base=>"xxx", :secret_token=>nil}

config/settings.yml から Encrypted Secrets を参照しているコードを取り除くと見えるようになる。

結論

というわけで config/settings.yml の中に Rails の Encrypted Secrets を混ぜて使うと危険っぽいです ☢️

Anker 製品には全幅の信頼を寄せているのだけど、購入したイヤフォンが立て続けに 1 年もたずに壊れてしまって安物買いの銭失い感を味わった。

↑で買った Anker のイヤフォン、イヤービースが外れやすくなってていつかなくなるだろうなぁと思ってたけど今日なくなった。 Anker のイヤフォンは二代目で、値段が安いわりに音はまぁまぁ良いから気に入っていた。二代目のやつはアーム式でジョギングでも快適に使えてた。ただ耐久性に難があると思う。先代は micro USB の充電ポート周辺のプラスチックが割れてぶっ壊れたし、イヤーピースも空港で外れてなくなった。イヤーピースは特殊形状なので他の部品を買って取り付けるわけにもいかないのが困る。値段や音質、機能には満足してるんだけど、もうちょい高いやつを買って使った方がよいのかなぁという気がする。

Archive ページにカテゴリごとの記事件数を表示する機能を追加した。

portal shit!.png

API でカテゴリごとの記事件数を返すのではなく、 JavaScript だけで entries.length を数えるようにしている。 React で関連コンポーネントが描画されたあとにいい感じに数える処理をトリガーする方法が分からず、描画完了後 1000msec 以内で 100msec ごとに記事数を数える処理を実行している。あまり賢い実装方法ではないと思うけど、一番記事数が多い 2006 年でも 600msec くらいで Ajax のレスポンスは返ってくるのでまぁ実用上問題はない。

こうして見ると、 2011 年から一切映画についてブログに書いてないことが分かる。さすがに年に一本も映画を見ないということはなくて、年に二、三本は絶対見ていると思う。以前は基本的に映画館で見た映画の感想を書くようにしていたので、映画館に行かなくなった(行けなくなった)せいで映画の記事を書かなくなったんだろうなぁと思う。

自分のブログに機能を追加することでここ数年の生活の傾向が分かるのが面白い。実は昨日、 Sunset Live の記事を書いたのも音楽について全然書いてないことに気づいたからなのであった。

Sunset Live 2017

今年の夏は久々に Sunset Live に行った。福岡に引っ越してくる前の 2010 年の 9 月に行った以来なので 7 年ぶりだった。夫婦で酒を飲みたかったので JR とシャトルバスを乗り継いで行ったが、 10 時半頃に着いた筑前前原駅のバス乗り場は異常な混み具合で、結局会場に着いたのは 12 時過ぎだった。 Sunset Live はやはり早めに家を出て向かわないと厳しい。

Spotify 内で流れる BOSE の CM で知った The fin. という神戸出身のバンド(シューゲイザーっぽい音楽)が目当てで行ったけどいろいろ新たな音楽に触れることができて良かった。

まずそれまで食わず嫌いであまり聞いてなかった Suchmos のライブ演奏を聴くことができたのがよかった。和製 Jamiroquai という話は耳にしていたけど、確かに良いバンドだと思った。

次に PETROLZ の音楽を聞くことができたのがよかった。惜しむらくは PETROLZ の演奏中、絶賛夫婦げんか中でステージの正面で聞くことができず、メインステージの裏手の土手に体育座りをして聞いていた。反芻する度にだんだん良さがこみ上げてきて、 Sunset Live 後一ヶ月間くらいはずっと PETROLZ の Fuel を聞いてた。 PETROLZ にはすっかりハマってしまって来週福岡であるライブに行きたいと思ったが、すでにチケットは売り切れでチケットキャンプでは ¥27800/枚 😱 。貴重なライブ演奏をステージ裏で体育座りして聞いていたことが悔やまれる。

もちろん目当てで行った The fin. の演奏も良かった。あまりお客さんに彼らのことを知っている人が多くはなさそうなのが残念だったが、ライブで幻想的な Night Time を聴くことができて満足だった。

ecs-deploy-flow

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導入した。自動テスト、コンテナイメージのビルド、デプロイには CircleCI を利用している。 .circleci/config.yml は以下のような感じ。

version: 2

shared: &shared
  working_directory: ~/app
  docker:
    - image: xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app
      environment:
        PGHOST: 127.0.0.1
        PGUSER: user
        RAILS_ENV: test
        REDIS_HOST: localhost
    - image: circleci/postgres:9.6-alpine
      environment:
        POSTGRES_USER: user
        POSTGRES_PASSWORD: password
    - image: redis:3.2-alpine

jobs:
  build:
    <<: *shared
    steps:
      - checkout
      # Restore bundle cache
      - &restore_cache
        type: cache-restore
        key: app-{{ arch }}-{{ checksum "Gemfile.lock" }}
      # Bundle install dependencies
      - &bundle_install
        run: bundle install -j4 --path vendor/bundle
      # Store bundle cache
      - &save_cache
        type: cache-save
        key: app-{{ arch }}-{{ checksum "Gemfile.lock" }}
        paths:
            - vendor/bundle
      # Database setup
      - &db_setup
        run:
          name: Database Setup
          command: |
            bundle exec rake db:create
            bundle exec rake db:structure:load
      - type: shell
        command: bundle exec rubocop
      # Run rspec in parallel
      - type: shell
        command: |
          mkdir coverage
          COVERAGE=1 bundle exec rspec --profile 10 \
                            --format RspecJunitFormatter \
                            --out /tmp/test-results/rspec.xml \
                            --format progress \
                            $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)
      # Save artifacts
      - type: store_test_results
        path: /tmp/test-results
      - type: store_artifacts
        path: coverage

  generate-doc:
    <<: *shared
    steps:
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache git openssh ca-certificates
      - checkout
      - *restore_cache
      - *bundle_install
      - *save_cache
      - *db_setup
      # Generate document
      - run:
          name: Generate API doc
          command: |
            AUTODOC=1 bundle exec rake spec:requests
      - run:
          name: Generate Schema doc
          command: |
            diff=$(git diff HEAD^ db)
            if [ -n diff ]; then
              bundle exec rake schema_doc:out > doc/schema.md
            fi
      - run:
          name: Setup GitHub
          command: |
            export USERNAME=$(git log --pretty=tformat:%an | head -1)
            export EMAIL=$(git log --pretty=tformat:%ae | head -1)
            git config --global user.email "${EMAIL}"
            git config --global user.name "${USERNAME}"
      - run:
          name: Push updated doc to GitHub
          command: |
            git add doc
            git commit --quiet -m "[ci skip] API document Update

            ${CIRCLE_BUILD_URL}"
            git push origin ${CIRCLE_BRANCH}

  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache \
              py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install \
              docker-compose==1.12.0 \
              awscli==1.11.76
            curl https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy \
              && chmod +x /usr/bin/ecs-deploy
      - restore_cache:
          keys:
            - v1-{{ .Branch }}
          paths:
            - /caches/app.tar
      - run:
          name: Load Docker image layer cache
          command: |
            set +o pipefail
            docker load -i /caches/app.tar | true
      - run:
          name: Build application Docker image
          command: |
            docker build --file=docker/app/Dockerfile --cache-from=app -t organization/app .
      - run:
          name: Save Docker image layer cache
          command: |
            mkdir -p /caches
            docker save -o /caches/app.tar organization/app
      - save_cache:
          key: v1-{{ .Branch }}-{{ epoch }}
          paths:
            - /caches/app.tar
      - run:
          name: Push application Docker image to ECR
          command: |
            login="$(aws ecr get-login --region ap-northeast-1)"
            ${login}
            docker tag organiation/app:latest xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest
            docker push xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest
      - run:
          name: Deploy container
          command: |
            ecs-deploy \
              --region ap-northeast-1 \
              --cluster app-dev \
              --service-name puma \
              --image xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest \
              --timeout 300

workflows:
  version: 2
  build-and-generate-doc:
    jobs:
      - build
      - generate-doc:
          requires:
            - build
          filters:
            branches:
              only:
                - master
      - deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - master
  1. master ブランチに対して出された Pull Request が Merge される
  2. CircleCI でテストが実行される
  3. テストが成功すると CircleCI 上からデプロイが行われる
    • コンテナイメージをビルド
    • ビルドしたイメージを AWS ECR にプッシュ
    • プッシュしたイメージを利用するタスクを AWS ECS に作成
      ecs-deploy 任せ
    • 古いコンテナから新しいコンテナに LB 切り替え
      こちらも ecs-deploy にやってもらってる
  4. CircleCI 上実行された Request Spec で自動生成された API ドキュメントを GitHub にプッシュ

コードが Merge されると勝手に確認環境にデプロイされるので、クライアントサイドの開発者からデプロイを頼まれて対応する必要がないし、クライアントサイドの人はいつでも最新の API ドキュメントを GitHub 上で確認できる。 API ドキュメントは手動更新ではなくテストから自動生成されるので、ドキュメントと実際の API の挙動が異なる、というありがちな問題も回避できる。

自分としては結構頑張ったつもりだったんだけど、「それ ECS でやる意味あるの? というか Docker じゃなくて普通の EC2 インスタンスに Capistrano でデプロイするのでよくね?」というツッコミが入った。デプロイフローで CircleCI への依存度が強すぎる、イメージのビルドとデプロイに時間がかかりすぎるし、ちょっとした typo の修正のためにイメージをビルドしたりとかあり得ない、 Docker を使うにしても ECS は使わず、 EC2 で Docker を動かし、コンテナがマウントしたディレクトリに Capistrano でデプロイするべき、という意見だった。このときぐぬぬとなってしまってあまりうまく答えられなかったので考えられるメリットを書き出してみる。

確かに Docker と ECS による環境を構築するのには時間がかかる。デプロイのためにそこそこでかいイメージをビルドしてプッシュするというのも大袈裟だ。加えて Production で運用するとなるとログの収集やデータベースのマイグレーションなど、考えなければならない問題がいくつかある1

ただコンテナベースのデプロイには以下のようなメリットがあると思う。

環境のポータビリティー

まず Ruby や Rails などのバージョンアップが容易になる。手元で試して確認した構成とほぼほぼ同じイメージをデプロイできる。デプロイ前にサーバーに新しいバージョンの Ruby をインストールしたりしなくて済むし、手元ではエラーにならなかったのに本番でエラーになった、というようなケースを減らすことができる。

サーバー構築手順のコード化

人数が少ない会社で専業のインフラエンジニアもいない状況だと Chef や Puppet でサーバーの構成管理をし、複数台あるサーバー群の管理をすることは難しい。 Dockerfile に手順を落とし込み、 Docker さえ入ってたらあとは何も考えなくて良いというのはとても助かる。少なくとも秘伝のタレ化しやすいサーバーの構築手順がコード化され、コードレビューのプロセスに載せることができる

迅速なスケール

AWS ECS のようなマネージドコンテナサービスと組み合わせて使えばスケールアウトが楽ちん極まりない。 AWS マネジメントコンソールか cli で操作するだけで簡単にスケールさせることができる。スケールに際して LB に組み込む前にプロビジョニングしたり最新のコードをデプロイしたりする必要もない。

デプロイ失敗が減る

Capistrano によるデプロイはデプロイ対象が増えてくると SSH が不安定になりデプロイに失敗することが増えてくる。 ECS のような AWS の仕組みに載せることで、イメージを ECR にプッシュさえできれば IaaS 側でよろしくやってくれるというのはとても良い。

以上のようなところだろうか。まだ Production に投入するところまでは持って行けてないので、今の自分の考察が正しいのかどうかをこれから検証していきたい。

関連してそうな記事

📝 CircleCI と autodoc で Rails API のドキュメントを自動更新


  1. いまは先人がいっぱいいるのでログの集約もマイグレーションも情報はいっぱいあると思う 

CircleCI.png

もうすぐ Ruby 2.5 が出そうだけど、このブログの Ruby のバージョンを 2.4 に上げた。

Ruby 2.4 がリリースされたあとすぐに Lokka を Ruby 2.4 に対応させようと頑張ってみたのだけど、 Ruby 2.4 に上げるためには ActiveSupport のバージョンアップが必要だった。しかし padrino-helper 0.11.4.1 が古いバージョンの ActiveSupport に依存しており、 Ruby 2.4 に対応した ActiveSupport を利用するためには padrino-helper をバージョンアップする必要があった。 padrino-helper をバージョンアップしてみると 0.12 から大幅な変更が入ったようで、ビューの表示がぐちゃぐちゃになった。 layout が適用されず中身の partial ビューだけ表示されたり、 HTML が過剰にエスケープされたり。 padrino-helper は 0.11 時代にあった脆弱性を修正して標準ですべての文字列出力を escape するようになったっぽい。しかし Lokka の方がそれに対応できておらずビューがぐちゃぐちゃになっているようだった。

Lokka はヘルパーメソッドやモデルで HTML を文字列から生成しているところがあって、そういうところをこまめに html_safe していったところ余分なエスケープは解消されていった。利用している gem でも文字列から HTML タグを生成しているところがあったので、そういうところもつぶさに調べていって無心で html_safe したり mark_safe していった。

とりあえずこのブログを Ruby 2.4.2 でしばらく運用してみて問題なかったら Lokka 本体の方に Pull Request を出すことにしよう。

あと今回ついでに CircleCI でテストしてテストが通ったら勝手に Production に deploy されるようにしておいた。 CircleCI ほんと便利。

追記 2017-12-03

Pull Request 出しておきました。