Kindleアプリで既読にならない

私はiPadKindleアプリで書籍を読んでいることが多いんですが、確実に最後まで読み切っているのにも関わらず既読の棚に移動しないという現象に1週間ほど悩まされていました.

結論としては、アプリの不具合でも何でもなくてiPadを再起動すれば解決するだけの話だったようです. どうやら起動しっぱなしだと、Kindleだけではなく他のアプリでも様々な不具合が発生するようで、 似たような現象は端末の再起動をとりあえずすれば良くなるというもののようです.

モバイルアプリの開発者ではなく軽く作ったことがある程度なので、何故こういう現象になりうるのかが少し気になりますね.

これからはちゃんと再起動しようと思いました.

MkDocsでmainブランチを利用する

昨今、技術界隈でもポリコレが重要視されている気がする世の中です. GitHubのデフォルトブランチがmainブランチに変更されていますが、MkDocsではmasterブランチがデフォルトのままです. この場合、生成されたHTMLの編集リンクはmasterブランチが参照されるため、GitHubで管理されている場合は404ページが表示されてしまいます.

そこで今回は、MkDocsでmainブランチの編集画面を開く設定を書いておきます.

TL; DR

  • mkdocs.ymlにedit_uri: edit/main/docs/ を追記する

mainブランチの編集画面を開く

公式ドキュメントのedit_uriが今回利用する設定になります. 他の設定値よりも色々と書かれていますが、GitHubで管理しているリポジトリがmainブランチという前提で話を勧めているのため、

f:id:corrupt952:20210226054427p:plain

の部分を参考にしてedit_uriを追記します.

On GitHub and GitLab, the default "edit" path (edit/master/docs/) opens the page in the online editor.

GitHubとGitLabは、edit_uriedit/master/docs/がデフォルトで設定されるということが分かります. というわけで、値のmaster部分をmainに変更して値をmkdocs.ymlに追記すればOKです.

以下がその例です.

site_name: In Docs - MkDocs Prj Templates
repo_url: https://github.com/corrupt952/mkdocs-prj-templates
# これを追記
edit_uri: edit/main/docs/

【随時更新】 2021年買ってよかったもの

2021年に買ってよかったものを随時更新していきます!

家電

HHKB Professional HYBRID Type-S

購入の決め手は、元々HHKB Professinal2を使っていたということと、無線キーボードが欲しいという気持ちが2年間ぐらい続いたことです.
実際に使ってみると、思っていたよりもかなり使いやすく電池の持ちも問題なさそうです.

メリットは、

  • Type-Sモデルなので通常のHHKBと比べて静かなタイプ音
  • リモートワークで複数PCを使っているけれど、PC間の切り替えが容易に行える
  • HHKB慣れしてるので入力しやすい

デメリットは、

  • 値段が高い(35,000円ぐらい)
  • Type-S全般の話だけど、タイプ音が特徴的なので気に入らない人はいる

です.

洗濯乾燥機(BD-SX110FL)

同僚からオススメされたという経緯もあり、引越し後即購入してみました. 実際に使ってみて感じたメリットは、

  • 乾燥機能がついている
  • 洗剤・柔軟剤の自動投入

になります. もちろんデメリットというか面倒な点もあって

  • フィルター関連は都度掃除しなければならない

という点です. とはいえ、圧倒的に便利なので洗濯乾燥機は是非購入検討をしてみて良いかと思います!

臭い戻りが気になるという口コミを見かけますが、これはいくつかの対策を行うことで防げるようなので問題ないかとは思いますが、 心配な方は日立以外のメーカーをしていた方が良いかもしれません.

Hugo向けのDockerfile最新版

個人サイトの www.khasegawa.net からブログをはてなブログに切り出したことで、テーマも変更しました.
それに伴いコンテナイメージを作り直したので、その時のDockerfileを書いておきます.

ちなみに最近のHugoのテーマでは、Sass/SCSSのコンパイルが必要になる場合もあるため、 インストールするHugoはextendedバージョンをインストールしています.

FROM ubuntu:20.04
RUN apt-get update \
    && apt-get install -y --no-install-recommends wget ca-certificates git bash make \
    && wget -O hugo.deb https://github.com/gohugoio/hugo/releases/download/v0.81.0/hugo_extended_0.81.0_Linux-64bit.deb \
    && dpkg -i hugo.deb \
    && rm hugo.deb \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /app

個人ブログをはてなブログに移行しました

ほぼ毎年ブログを変えてるような気がしますが、今回は落ち着くことになりそうです.

以前、個人ブログを変更した時の話はこれ

khasegawa.hatenablog.com

Hugoを使っていて不便に感じたこと

元々Hugoを使ってブログの記事内容を含めてwww.khasegawa.netを管理していたのですが、
Hugoを使ってブログを管理する際に1点だけデメリットがありました.

それはブログ記事に画像を埋め込むときです.

恐らくこれmacOSを使っている人は多少マシだとは思いますが、
私の普段の開発環境はWindows+WSL2(Ubuntu)になります.
この環境で画像入りのブログ記事を作る場合にどういった手順が必要になるのかと言うと、

  1. 記事作成スクリプトを実行(画像置き場も作成される)
  2. 記事を書く
  3. Windows側にあるファイルをWSL側にある画像置き場にmvなどで移動する
  4. 記事内にfigureなどのショートコードを利用して画像を参照させる

といった手順になります.
そこまで面倒じゃないように思えるかもしれませんが、3と4の中では移動したりファイル名を変更したり、パスを考えてfigureを呼び出したりと
意外と作業が多く画像を埋め込みたい時にかなり面倒に感じていました.
はてなブログに移行したとは言っても完全に解消されるわけではありませんが、
今の運用よりは圧倒的に楽になりそうです.

NewRelicの新料金プランについてまとめる

昨年の夏頃にNewRelicでは新料金プランを打ち出していました.

newrelic.com

この頃は私が関わっているところでは、料金プランの変更が次回更新時だったため詳細について見るのを後回しにしていました.
そしてそろそろ更新タイミングに差し掛かるため、新料金プランがどういった料金体系や仕組みになっているのかをまとめます.
間違っているところもあるかしれないのでそこはご注意ください.

料金について

旧料金プランでは、利用する製品ごとにホスト数やAU数による従量課金でした.
新料金プランでは、Full userというユーザ数課金と、無料枠を越えた場合の従量課金の2軸になっています.
料金の詳細についてはNewRelicのページを見てほしい.

newrelic.com

無料枠を越えた場合の従量課金については、どれぐらいになるのかが想定できないので端折りますが、
ユーザ数課金は1開発者として考えるとかなり高くなる可能性があります.
新しい料金プランでは、Basic userとFull userという2種類のユーザモデルが存在しており、
Basic userは無料で使えるが、Full userはそのユーザ数分の料金が請求されます.
恐らく大部分の開発者はFull userでないと困る可能性が高く、開発者が多い組織では開発者数分の料金が徴収されます.
具体的にどれぐらいの料金なのかはページに表示されていないため、ここでは触れないが組織によっては驚くような徴収額になる可能性が高いです.
とはいえ、利用できる機能や管理しているサービスやホスト数によっては全然ペイできるとは思う価格帯だとは私は思っています.

ちなみに本家の方のページには日本のページにはないStandardなるプランがあります.

newrelic.com

Basic userとFull userの違いについて

NewRelic公式ドキュメントにユーザモデルの違いについてのページがあります.

https://docs.newrelic.co.jp/docs/accounts/accounts-billing/new-relic-one-user-management/new-relic-one-user-model-understand-user-structure

それぞれのユーザでできることを見る限り、APMやBrowserなどでパフォーマンスやエラーなどをチェックする人というか、
基本的に開発者はFull userでなければNewRelicを導入する意味はないです.

下にドキュメントから抜粋しておきます.

Full-Stack Observability

機能 Full user Basic user
Application perfomance monitoring(APM) UI
Infrastructure monitoring UI
Digital Experience Monitoring(Browser, Mobile, Synthetics) UI
Serverless monitoring UI
Logs in context with other UI experiences
Synthetics checks
New Relic Edge with Infinite Tracing (tail-based sampling)
Subscribe to New Relic One catalog apps
Assorted curated UI experiences (distributed tracing, Kubernetes cluster explorer, workloads, etc.)

Applied Intelligence (AI)

機能 Full user Basic user
Proactive Detection ✔(read-only)
Incident Intelligence ✔(read-only)

Telemetry Data Platform

機能 Full user Basic user
Data ingest from any source (Metrics, Events, Logs, Traces)
Alerts and notifications
Interactive query interface
Custom charts and dashboards (not New Relic-built)
Encryption at rest
Standard data retention
NerdGraph (GraphQL) API
Security and compliance
Integrations
Data management
Logs UI
Build custom New Relic One apps

おわりに

実際にNewRelicの方と話をして実際にいくらになるのかは、事前に見積りを取っておくことをオススメします.
もしも、見積もりをとった上でペイできないような料金になりそうであれば、開発体制の見直しや別サービスの導入をする時間があった方が良いはずですからね.

CloudWatchアラーム一覧を表示する

どのリージョンにどんなCloudWatch Alarmがあるのかを知りたかったので、Bashスクリプトを書きました. 利用するツールは、jqとAWS CLIv2の2つ.

#!/usr/bin/env bash

# 利用可能なリージョンを取得
get_regions() {
    aws ec2 describe-regions | jq -r '.Regions[].RegionName'
}

# 指定されたリージョンのアラームを取得し、「リージョン\tアラーム名」というTSV形式で出力
get_alarms() {
    local region="$1"
    aws --region $region cloudwatch describe-alarms | jq --arg REGION "$region" -r '.MetricAlarms[] | [$REGION, .AlarmName] | @tsv'
}

main() {
    for region in $(get_regions); do
        local alarms=$(get_alarms $region)
        if [ -n "$alarms" ]; then
            echo "$alarms"
        fi
    done
}
main $*