私はiPadのKindleアプリで書籍を読んでいることが多いんですが、確実に最後まで読み切っているのにも関わらず既読の棚に移動しないという現象に1週間ほど悩まされていました.
結論としては、アプリの不具合でも何でもなくてiPadを再起動すれば解決するだけの話だったようです. どうやら起動しっぱなしだと、Kindleだけではなく他のアプリでも様々な不具合が発生するようで、 似たような現象は端末の再起動をとりあえずすれば良くなるというもののようです.
モバイルアプリの開発者ではなく軽く作ったことがある程度なので、何故こういう現象になりうるのかが少し気になりますね.
これからはちゃんと再起動しようと思いました.
昨今、技術界隈でもポリコレが重要視されている気がする世の中です. GitHubのデフォルトブランチがmainブランチに変更されていますが、MkDocsではmasterブランチがデフォルトのままです. この場合、生成されたHTMLの編集リンクはmasterブランチが参照されるため、GitHubで管理されている場合は404ページが表示されてしまいます.
そこで今回は、MkDocsでmainブランチの編集画面を開く設定を書いておきます.
edit_uri: edit/main/docs/ を追記する公式ドキュメントのedit_uriが今回利用する設定になります. 他の設定値よりも色々と書かれていますが、GitHubで管理しているリポジトリがmainブランチという前提で話を勧めているのため、
の部分を参考にしてedit_uriを追記します.
On GitHub and GitLab, the default "edit" path (edit/master/docs/) opens the page in the online editor.
GitHubとGitLabは、edit_uriにedit/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年に買ってよかったものを随時更新していきます！
日立 【左開き】11．0kgドラム式洗濯乾燥機 ビッグドラム ロゼシャンパン BD-SX110FL N
同僚からオススメされたという経緯もあり、引越し後即購入してみました. 実際に使ってみて感じたメリットは、
になります. とはいえ、デメリットというか面倒な点ももちろんあって
という点です. とはいえ、圧倒的に便利なので洗濯乾燥機は是非購入検討をしてみて良いかと思います！
臭い戻りが気になるという口コミを見かけますが、これはいくつかの対策を行うことで防げるようなので問題ないかとは思いますが、 心配な方は日立以外のメーカーをしていた方が良いかもしれません.
個人サイトの 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
ほぼ毎年ブログを変えてるような気がしますが、今回は落ち着くことになりそうです.
以前、個人ブログを変更した時の話はこれ
元々Hugoを使ってブログの記事内容を含めてwww.khasegawa.netを管理していたのですが、
Hugoを使ってブログを管理する際に1点だけデメリットがありました.
それはブログ記事に画像を埋め込むときです.
恐らくこれmacOSを使っている人は多少マシだとは思いますが、
私の普段の開発環境はWindows+WSL2(Ubuntu）になります.
この環境で画像入りのブログ記事を作る場合にどういった手順が必要になるのかと言うと、
といった手順になります.
そこまで面倒じゃないように思えるかもしれませんが、3と4の中では移動したりファイル名を変更したり、パスを考えてfigureを呼び出したりと
意外と作業が多く画像を埋め込みたい時にかなり面倒に感じていました.
はてなブログに移行したとは言っても完全に解消されるわけではありませんが、
今の運用よりは圧倒的に楽になりそうです.
昨年の夏頃にNewRelicでは新料金プランを打ち出していました.
この頃は私が関わっているところでは、料金プランの変更が次回更新時だったため詳細について見るのを後回しにしていました.
そしてそろそろ更新タイミングに差し掛かるため、新料金プランがどういった料金体系や仕組みになっているのかをまとめます.
間違っているところもあるかしれないのでそこはご注意ください.
旧料金プランでは、利用する製品ごとにホスト数やAU数による従量課金でした.
新料金プランでは、Full userというユーザ数課金と、無料枠を越えた場合の従量課金の2軸になっています.
料金の詳細についてはNewRelicのページを見てほしい.
無料枠を越えた場合の従量課金については、どれぐらいになるのかが想定できないので端折りますが、
ユーザ数課金は1開発者として考えるとかなり高くなる可能性があります.
新しい料金プランでは、Basic userとFull userという2種類のユーザモデルが存在しており、
Basic userは無料で使えるが、Full userはそのユーザ数分の料金が請求されます.
恐らく大部分の開発者はFull userでないと困る可能性が高く、開発者が多い組織では開発者数分の料金が徴収されます.
具体的にどれぐらいの料金なのかはページに表示されていないため、ここでは触れないが組織によっては驚くような徴収額になる可能性が高いです.
とはいえ、利用できる機能や管理しているサービスやホスト数によっては全然ペイできるとは思う価格帯だとは私は思っています.
ちなみに本家の方のページには日本のページにはないStandardなるプランがあります.
NewRelic公式ドキュメントにユーザモデルの違いについてのページがあります.
それぞれのユーザでできることを見る限り、APMやBrowserなどでパフォーマンスやエラーなどをチェックする人というか、
基本的に開発者はFull userでなければNewRelicを導入する意味はないです.
下にドキュメントから抜粋しておきます.
| 機能 | 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.) | ✔ | ☓ |
| 機能 | Full user | Basic user |
|---|---|---|
| Proactive Detection | ✔ | ✔(read-only) |
| Incident Intelligence | ✔ | ✔(read-only) |
| 機能 | 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 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 $*