2021年ビール10選

今年もこのランキングの季節がやってまいりました。今年飲んだビールから、印象に残った10本を選んでいきます。順番は、飲んだ時間の順番です。

Hotcake Hazy IPA - Far Yeast Brewing

f:id:katzchang:20211206214532j:plain

変わり種に見えて、甘そうに見えるけど、飲んでみると意外とふつうにちゃんとしっかりとしたHazy IPA。もちろん香りは甘く、メープルシロップのような感じです。

faryeast.com

Passiflora Hazy IPA - VERTERE

f:id:katzchang:20211206214824j:plain

その名の通り、トロピカルフルーツの中に百合のような華やかな香りがよかった。

verterebrew.com

2021年限定 Session IPA - 軽井沢高原ビール

f:id:katzchang:20211206215010j:plain

オレンジ感の高いジューシーさ。転職前の有給消化中、雪の中で飲んだという思い出です。

yohobrewing.com

Hazy Tropics - Shared Brewery

f:id:katzchang:20211206215238j:plain

パイナップル感の高い。夏くらいにあったやつかな。ご近所のブルワリーで、新鮮なビールをいつも頂いております。

醸造や缶詰めなどの設備が徐々に充実してきているらしく、来年あたりは皆さん手に入りやすくなりそう。見つけたら飲んでみてください。

www.jbja.jp

サッポロ セブンプレミアム 上富良野佐藤さんのホップ畑から

f:id:katzchang:20211206215721j:plain

大手ビールからこの1本が印象的だった。爽やかなホップの香りがいい。佐藤さんなかなかやりよる。

www.sapporobeer.jp

PALE ALE nonno - 忽布古丹醸造

f:id:katzchang:20211206215923j:plain

香りが良く軽めに飲めるので、広くおすすめできる。

hopkotan.com

Early Tide - BLACK TIDE BREWING

f:id:katzchang:20211206220223j:plain

第一印象の香りがとてもよかった。しっかり苦味もあり、バランスの良いIPA

blacktidebrewing.com

Over Drive Pale Ale - Y.MARKET BREWING

f:id:katzchang:20211206220554j:plain

重めでしっかり苦めなワイマーケットの中でも比較的飲みやすいバランス感だった気がする。

craftbeer.nagoya

SUN - Uchu Brewing

f:id:katzchang:20211206220824j:plain

宇宙は色々飲んでどれも印象が良く選びにくいが、最近飲んだこれをとりあえず。これもバランスのいい系のIPAだったなー。

uchubrewing.com

Harmonic Dreams - West Coast Brewing

f:id:katzchang:20211206221119j:plain

WCBも選びにくいが、今日(!)飲んだこれを推しておきます。強烈フルーティな香りで口当たりがよく、かつ、アルコール度数が高めのせいか飲みごたえがあるという、高次元でまとめてきた感じがある。

www.westcoastbrewing.jp

ということで、

振り返ってみると好みの傾向がかなり出てるなぁという感じの10選になりました。限定醸造とかも多く、そうじゃなくても、小規模ブルワリーは醸造バッチごとに味わいが異なってくるという一期一会の世界です。このあたりのビールを飲みだしたのはちょうど去年の末くらいからだったと思うのですが、ステイホームな今年1年楽しませていただきました。来年はどうなるかなぁ、楽しみにしております。

さて、これはpyspa Advent Calendar 2021、12/6のための記事でした。pyspaの #bar チャンネルでは、ビールのみならずアルコール飲料の情報が日々交換されていて、とても有用でございました。ビール会したいね。

Nature Remo Eを使って、消費電力をNew Relicに送信する

Hey, NewRelic Advent Calendar 2020 - Qiita, 15日目の記事だよ!時差があるのは気にしないで!

電力消費量が気になる季節がやってまいりました。ということで、Nature Remo Eを使って電力消費マネジメントの第一歩目である「計測せよ」にチャレンジしてみます。

Nature Remo Eを買う

買ってください

Nature API Tokenを取得する

Remo Eを良い感じにセットアップしていただいて、 https://home.nature.global/ にログインしたらなんとなくtokenが発行できます。

New Relicに情報を送る

電力消費情報をNew Relicに送ることで、アラートを設定して不測の事態に対応したり、パフォーマンスを可視化し、コストをコントロールするためのインサイトを得たりができるようになります。

New Relicに情報を送る方法はいくつかあります。Infrastructureエージェントを動かしているならnri-flex設定はシンプルなのでおすすめではありますが、せっかくなので2020年春あたりから整備されてきた新しいNew Relic Metrics APIを使って、情報を送ることにしましょう。

Nature APIから情報を持ってくる

go-remoeというライブラリがなんとすでにあるので、ありがたく使ってみることにします。解説のブログ記事を見た感じでは、以下2つが候補になります:

  • 瞬時消費電力: その瞬間の消費電力。スピードメーター的なもの。
  • 期間当り(たとえば1分当り)の消費電力: ある期間の消費電力を出すためには、期間終了時の積算消費電力から期間開始時の積算消費電力を良い感じに(正方向と逆方向を適当に)引く必要がある。

瞬時消費電力は扱いが簡単そうです。一方、期間の消費電力を扱うにはなんかちょっと計算をする必要があるようで、うーんなかなか難しい。とりあえず生のデータだけNew Relicに送っておいて、計算は後で考えることにしましょう。

計測・送信間隔は雰囲気的に1分毎を想定してみます。crontabで毎分実行させたり、現代的にはAWSCloudWatch Eventsを使って毎分Lambdaをinvokeさせるような想定です(Lambda Handlerへの実装は、読者の課題とする)。

New Relicに送る

New Relic Metrics APIを眺めてみると、Metrics APIを直接使う方法や、各言語のテレメトリSDK経由で送る方法にたどり着きます。そのあたりから、newrelic-telemetry-sdk-goにたどり着いてみましょう。

メトリックは3種類あると記載されています:

Basic type Aggregated type Description Example
Gauge(ゲージ) AggregatedGauge ある時点での単一の値 部屋の温度
Count(カウント) AggregatedCount 何らかのイベントが起こった回数を記録する エラーの発生回数
Summary(サマリー) AggregatedSummary ある時間間隔における、カウント、合計、最小、最大を記録する 1分あたりのHTTPリクエストのスループットやレスポンスタイムを記録する

Remo Eで取得できる値は、いずれもある瞬間での値なので、とりあえずゲージとして突っ込んでおきましょう。

コードはこうなりました。Nature API Token, New Relic Insert APIはそれぞれ、環境変数として設定しています。

package main

import (
    "context"
    "github.com/reeve0930/go-remoe"
    "github.com/newrelic/newrelic-telemetry-sdk-go/telemetry"
    "time"

    "os"
)

func main() {
    token := os.Getenv("NATURE_API_TOKEN")
    remoClient := remoe.NewClient(token)
    hervester, _ := telemetry.NewHarvester(telemetry.ConfigAPIKey(os.Getenv("NEW_RELIC_INSERT_API_KEY")))

    data, _ := remoClient.GetRawData()
    for _, d := range data {
        hervester.RecordMetric(telemetry.Gauge{
            Timestamp: time.Now(),
            Value:     float64(d.MeasuredInstantaneous),
            Name:      "remoe.MeasuredInstantaneous",
            Attributes: map[string]interface{}{
            "modelId": d.ModelID,
        },
        })
    }
    hervester.HarvestNow(context.Background())
}

New Relicで見てみる

New Relic Oneを開いて、右上のQuery Your Dataからメトリックの情報をクエリできます。Data Explorerから行っても良いですし、たとえばNRQLはこんな感じに発行してみましょう。

FROM Metric SELECT average(remoe.MeasuredInstantaneous) facet modelId TIMESERIES 

f:id:katzchang:20201216024445p:plain
データが良い感じに表示されている様子

データが突っ込まれましたね!

まとめ

こんな感じに、コンパクトなスクリプトでNew Relicにメトリック情報を放り込むことができるという例でした。コード全体はnewrelic-remoeで公開していますので、ご参考になれば幸いです。詳細が気になる方は@katzchangまでメンションなどいただければと思います。仕事だぜm,

キーボードを作ってみた話を書きます

こんにちは、pyspa Advent Calendar 2020の3日目の投稿になります。

今年の思い出としては長らく続く在宅勤務だと思いますし、みなさんもいろいろなガジェットで在宅勤務を成功に導いていらっしゃることと存じております。

ということで、キーボードを作りました。pyspaの皆さまにはお世話になりました。

f:id:katzchang:20201109220044j:plain
イメージ図

背景

決断に至るストーリーはだいたいこんな感じです:

  • Macbook Proのキーボードをそのまま使っていたが、温度が熱くなりがちなので、夏にめっちゃストレスが高まった
  • 会社支給でMagic KeyboardとTrackpadがもらえるので届けてもらったが、今ひとつポジションが定まらなかった
  • Samuraismさんの#MAGICTRAYPALMが良いらしいと聞き、Magic Keyboard対応の試作品を送ってもらった(ありがとうございます!!)が、残念ながらあまり手になじまず(Magic Keyboardは薄くて強度設計が難しいとのこと)

以前から分割キーボードに興味があったこともあり、もうこれは移ってしまおうということであれしました。

買い物

キーボードは主に遊舎工房の物理店舗で買いました。通販じゃパーツの声が聞こえないだろ?*1

工具は主にAmazonで買いました。ぴえんキーキャップはKochi Keyboardから。

キーボード

  • Ergodash mini: 分割で数字キーなしを選びたかった(以前から数字キー打鍵が苦手だった)
  • Sakurio: 静音で軽
  • R2 XDA 40v2 Dye-sub keycaps: 地味めだけどかわいい
  • マグネットでつながるUSBケーブル: チップのUSB端子が壊れやすいらしいので便利とのこと
  • リストレスト: 分割キーボード用のやつを贅沢にも2つ横につなげて、ダラっと手首を乗せられるようにしてます。サイズ感をたしかめるために、まずはそのへんの本とかで試すと良い。
  • ぴえんキーキャップ: 🥺、日本語変換キーに実用してしまってる。手触りで判別できるので意外と便利。

一度加工で失敗したので、ダイオードをAmazonで別途追加注文とかしてます。LEDキラキラは難しそうなので付けていません。

工具と消耗品

あとは家にあったニッパーとか、作業台みたいなのもあるといい。木の板をつかいました。

工作

いろいろあった*2けど頑張った。

f:id:katzchang:20200924161035j:plainf:id:katzchang:20200924174852j:plainf:id:katzchang:20200924180813j:plainf:id:katzchang:20200924211353j:plainf:id:katzchang:20200925213439j:plainf:id:katzchang:20200925223933j:plain
加工頑張ったイメージ図

結果と今後

腱鞘炎が遠ざかり、姿勢が良くなったと言われました。今後は無線化したいけどうまく動かない。

以上、よろしくお願いいたします。

Ward Cunningham, the creator of the concept of technical debt, explained by himself.

This translation post is published under CC BY 3.0 based on the original article.

"Technical Debt" has been a hot topic in the world of system development, and is often on fire.

The creator of the concept of technical debt is Ward Cunningham. In 1992, he compared the first release of the code to debt in the Experience Report of the object-oriented international conference OOPSLA '92 ("Shipping first time code is like going into debt").

Ward Cunningham has made many contributions to the software world. He was the inventor of the Wiki, a mentor of XP and TDD's father Kent Beck, who imported the "pattern language" of the architectural world into the software with Kent Beck, also the one of the member of "Manifesto for Agile Software Development" (for more information, see "パターン、Wiki、XP ~時を超えた創造の原則" or blog articles "君はWard Cunninghamを知っているか? 前篇後篇").

So, what was behind the idea that Ward invented the concept of technical debt? What did he think and why did he come up with this concept? In fact, Ward posted a little less than a five-minute video on YouTube in 2009 explaining the background of technical debt.

www.youtube.com

And the transcript of this video is posted on wiki.c2.com (that Ward himself first world developed Wiki), I have translated it as follows.

[Translation] Debt metaphor.

(The wiki translation follows in the original article.)

After the translation

What's surprising is that what Ward Cunningham is saying is quite different from the "technical debt" we envision.

The image we have in the term "technical debt" might be "crudely written code that prioritizes the release, and is left over without a clean rewrite" or "technical foundation (language, infrastructure or framework) that has become old". Or, Wikipedia in Japanese article states that "The Consequences of Haphazard Software Architecture and Unprepared Software Development". But these come from misunderstanding, Ward says.

According to Ward, the negative impact of debt is the productivity loss caused by the disconnect between the understanding gained with development and the system you are facing, not the maintainability (or clutter) of the code you're writing. Rather, he says, you should always do the best you can at the time when you're writing code.

For Ward, the debt repayment method is refactoring, and the purpose of refactoring is to eliminate the gap between their domain knowledge and the current program. In other words, this refactoring can be said to be something like “Refactoring toward deeper insight” in domain-driven design (DDD). The theme for domain-driven design is "to tackle the core complexity of software", as you know. Of course, the scope of resolving deviations is not only limited to refactoring, but also includes rearchitecting, I think.

The word "debt" tends to be more positive (as in capital) for those closer to management, and more negative (as in loans) for those closer to technology. The debt metaphor Ward is talking about is rather positive. The development approach of releasing software quickly and repeatedly, and learning from experience and hypothesis testing, is becoming more and more common today. In addition, Ward's use of the debt metaphor came about because he and the person he was describing happened to be developing the same financial software. But then, the strong word "debt" may have walked alone and created the current impression of technical debt.

By the way, the WyCash refactoring that led Ward to create the debt metaphor was a strong inspiration to Kent Beck and would appear in his later work, Test-Driven Development (Ward is the protagonist of the Introduction of the book, and the theme of Part 1, "Multilateral Currencies," is based on WyCash's domain objects).

And, Ward consistently says only "Debt" without "Technical". Now, I'm also curious who and why added "Technical", but I would like to quickly bring the translation to the world first.

メンテナンスウィンドウを使わない

6年ほど無停止のサービスを運用してきた私の経験からすると、メンテナンスウィンドウ、つまり計画的メンテナンスに対するアラート発砲を抑制する機能は、使わないほうがうまくいく。仕事の中でも度々メンテナンスウィンドウの話題が出てきたので、個人の見解としてまとめてみたい。

計画的メンテナンスの手順

対外的に無停止だとしても、内部的には停止を伴うメンテナンスをすることがある。たとえば、MySQLを止めることはたまにある。まずは、どのようにメンテナンスを進めていくのかを整理しよう。

内部的な停止を伴うメンテナンスの際は作業に必要な時間とともに、アラートが起こる範囲を予測し、予告しておく。予告の範囲を決めるのは単純で、アラートが届くだろうチャンネルにお知らせしておけばいい。以前のチームではメールとSlackチャンネルを使っていたので、そこに書いていた。準備はこれでいい。

メンテナンス作業が始まる(たとえばMySQLをフェイルオーバーさせる)と、何らかのアラートが出る。メンテナンスチームはAcknowledgeを送るのも良い。予告通りであれば、アラートを受けた人は作業を気にしつつ、作業がうまく進むことを期待するだろう。作業が終わり、サービスが動き出し、アラートが緑に変わる。平和な世界が戻る。

普通でしょ?

意図的にアラートを出す利点

予めアラートを抑制する手順と比較して、いくつかの利点がある。

アラートが適切に設定されていることを確認できる

内部サービス停止のアラートは滅多に起こるものではない。一度も発砲されていないアラートは適切に設定されていることを確認する手段はない。設定画面を注意深く見るくらい?人間の目は信用しないほうがいい。停止する範囲から期待されるアラートを洗い出して、実際に発砲されることを確かめよう。

メンテナンス終了がすぐに伝わる

予想していたよりも早く作業が終わった場合、アラートが収まることで必要な通知をすることができる。「メンテナンスは無事終わりました!」っていうお知らせを急がなくて良くなる。

手間が減る

メンテナンスウィンドウを適切に設定する手間を惜しむのは悪いことじゃない。俺たちは忙しいんだ!

まとめ

意図的にアラートを出す計画的メンテナンスの手法と利点について書いてみた。

もちろん、メンテナンスウィンドウを欲しているチームはあるだろう。その場合、ここで紹介した手法が適用できないか少し考えてほしい。適用が難しいかもしれない事情には興味があるので、ぜひ共有してほしい。

この話はもしかして、アラートの所有者は誰なのかという議論にもなるかもしれない。

New Relic LogsでCustom Attributeを追加する

こんにちは。 New Relic Advent Calendar 2019 - Qiita, 12/10の記事を始めます。

New Relic Logsは、Logを扱うサービスです。fluetndなどのログコレクターからログを突っ込みつつ、クエリしたり、アラートを設定できたりするやつです。

f:id:katzchang:20191210124422p:plain
ogs!

突っ込んだデータはInsightsでもクエリ可能なので、つまり、色々できそう。ということで、どこまで遊べそうかちょっと試してみます。

hostname, service_name

ドキュメントのとおりにfluentdで設定すると、とりあえずログが収集されはじめます。気づくと思いますが、ちょっと空欄のところがありますよね。

f:id:katzchang:20191210124933p:plain
HOSTNAME, SERVICE_NAMEがさみしい

とりあえず fluentd filterで足してみます

<filter **>
  @type record_transformer
  <record>
    hostname ${hostname}
    service_name "オーサムログ🚀"
  </record>
</filter>

fluentdを再起動して、ログをおくってみると…

f:id:katzchang:20191210130439p:plain
🚀

送られました!左側のHostnameフィルタなんかもいい感じに動きそうです。

更に項目を追加してみる

Insightsに入るということはつまり、カスタム属性を追加できるようなきがしますよね。やってみました。

how_awesome という項目を足して…

<filter **>
  @type record_transformer
  <record>
    hostname ${hostname}
    service_name "オーサムログ🚀"
    how_awesome "⭐⭐⭐⭐⭐"
  </record>
</filter>

fluetndを再起動、ログをおくってみると…

f:id:katzchang:20191210130725p:plain
⭐5つ!(3つしか表示されないが)

ご覧のとおり、Insightsからクエリ可能な感じになりました。Logsの画面上ではカスタム属性は表示されませんが、検索条件は補完されたりします。

f:id:katzchang:20191210130928p:plain
how_...

ということで、

今回のサンプルコードは↓のリポジトリにおいてあります。

github.com

ということで、New Relic Logsを簡単に動かしてみました。APMと組み合わせてつかえるLogs in Context もパブリックベータで公開中で、こちらも近々試してみようと思ってます。気になる方はご連絡ください!