あけましておめでとうございます。11月頃にMakuakeで応援購入したApple watch用のバングルが届いたので開封しました。 購入したのはAir bangle のべっ甲カラーです。 Air bangleはその名の通り、世にも珍しい(?)バングル型のApple watchバンドです。 鯖江のメガネ作りの技術で作られているそうです。 箱はこんな感じで、思っていたよりも高級感があります。クラウドファンディングで作られたモノはもっとがさつな袋に入ってくるものだと思っていたのですが、そうでもないようです。 中にはアダプタと本体、取扱説明書が入っていました。取説の内容はほとんどQRコードで、Apple watchへの装着方法や着け心地の調整方法などは動画で確認することができます。 保証も一年ついていて安心です。 色はこんな感じ。Makuakeのページ上で見たイメージよりは濃い色に見えます。 購入したのはApple watch 38/40/41mm用のサイズ4(17〜18.5cm)です。これまではソロループのサイズ9や、ブレイデッドソロループのサイズ8がちょうどいい、と思っていた位の腕の太さです。 おまけ(?)として専用のスタンドもついています。簡単な作りではありますが木製で悪くないです。 表から見ると木目が良い感じですが、実際は突板で、裏から見るとMDF材まんまなので表からだけ見ましょう。(makuakeのページを見るとチェリー突板/MDF材、とのことです) Apple watchに固定するプレート部分もきれいです。安モノだとこういう部分があまりきれいではなかったりするんですよね。 実際にApple watchに装着する際はこのアダプタを使用します。アダプタは購入時に黒かシルバーから選ぶことができますが、私のApple watchはミッドナイトカラーなので黒にしました。 もちろん、きちんとロック部分も実装されています。 平置きタイプのドックなどは使えないと思いますが、Amazonで売っている安価な横置きタイプの充電スタンド であれば問題無く使用できます。 今回購入したべっ甲カラーはまだ正式には発売前なのでクラウドファンディングが終了した現在は購入することができませんが、第一弾で販売された3色は公式サイト から購入できるようなので、気になった人は購入してみてください。 サイズは38/40/41mm Apple watch用と42/44/45mm Apple watch用でそれぞれ5サイズ展開、届いた後にサイズが合わなかった場合も無償で交換してくれるそうです。 なお、予想していたことではありますがキーボード操作をするときは邪魔になりますので、キーボード操作をするときはソロループ、外出時はAir bangleといった使い分けが必要そうです。

まぁ定番のネタですが、今年もいろいろ買ったので見ていきましょう。 車関連 Honda N-ONE 思ったより乗っているので、次に買い換えるときはもっとお金を掛けても良いな、という気持ち Anker PowerDrive III Duo 最近はカーチャージャーもUSB-Cのが有るんですね Anker PowerLine Ⅲ Flow USB-C & ライトニング ケーブル 車関連ではないけど車で使っているので。絡まない サムライプロデュース 超吸水 サムライタオル 大判 Lサイズ 洗車後はこれでほぼ一発 クロックス スウィフトウォーター エクスペディション 永遠にサンダルを履いている。これは運転用です アクアリウム ミナミヌマエビ GEX グラステリアフィット 200LOW コトブキ工芸 ミニフィットフィルターMF 寝室で一晩中動かしてても平気なくらい静か GEX クリアLED ピテラ 小さくて明るくて可愛い。神。 ゲーム Pokémon LEGENDS アルセウス Nintendo Switch Proコントローラー 勝手に動かないコントローラー、快適・・・ ガジェット類 グリーンハウス iPhone巻取り式充電ケーブル USB Type-C ライトニングケーブル 鞄に入れておくケーブルは巻き取り式派なんですよね グランサンク ブルーハムハム i select iPhoneケース ガジェットかどうかは微妙。ブルーハムハム可愛いですね TALENANA for Apple Watch フィルム 柔らかくないタイプのフィルム SwitchBot 温湿度計プラス APIの検証用に買っただけだったんだけど、プラスじゃない奴と比べて圧倒的に見やすい 日用品など ビホウマスク AG抗菌+ダブルフィルタ 横ワイドまっ白なやさしいマスク(個包装) 30枚入 別にこれ自体とかAG抗菌とかダブルフィルタとかに特別こだわりがあるわけではないけど、大きいサイズのマスクはきつくなくて良い アイリスオーヤマ 家具転倒防止伸縮棒ML ホワイト 今年、地震多かったですね。本棚が全然揺れなくなった ジョイ ジェルタブ 食洗機用洗剤 継続購入ではあるけれど、他の洗剤も使ってみてやっぱりこれが良くて戻ってきた レノア リセット 柔軟剤 完全に、ではないけど明らかにしわが少ないと思う バルクオム シャンプー 高いけど匂いが好き。だけど高い 書籍 以前から継続的に購入している続き物のコミック・小説などは除く...

例えば、サービスAでは登録されているけれどもサービスBには登録されていないユーザの一覧を得たい、という様な場合。もちろんdiffでよしなにやることもできますが、commも便利です。 例えば次の様にリストがあるとします。 サービスAのユーザーリスト(users_a.txt): 1 2 3 4 5 alice bob charlie dave oscar サービスBのユーザーリスト(users_b.txt): 1 2 3 4 5 charlie isaac justin mallory oscar これらに対してcommを使うと次の出力が得られます: 1 2 3 4 5 6 7 8 9 $ comm users_a.txt users_b.txt alice bob charlie dave isaac justin mallory oscar TABで揃えられた列がそれぞれ左から、Aにだけ存在する行、Bにだけ存在する行、Cにだけ存在する行、となっています。これだけだと別にそれほど便利ではないんですが、commはそれぞれの行を非表示にする事もできます。それぞれ、非表示にしたい行を-1 -2 -3で指定します。 Aだけに存在する行を表示する: 1 2 3 4 $ comm -23 users_a.txt users_b.txt alice bob dave 両方に存在する行を表示する: 1 2 3 $ comm -12 users_a.txt users_b....

GitHub ActionsとHugoを使用して静的サイト生成を行う場合、peaceiris/actions-hugo を使用するか、自分で適当にHugoをインストールするかのいずれかが一般的だと思います。このブログでは、セットアップ当初はpeaceiris/actions-hugoを使っていたのですが、最近debパッケージを自分でインストールする方式に切り替えました。 gohugoio/hugoのreleases から直接debパッケージを持ってきているので、peaceiris/actions-hugoとは違いlatest指定をする事ができず、Hugoの更新を手動で行う必要があり、ちょっと面倒だな〜と感じていました(しかもHugoは結構開発が活発で、更新もはやいんですよね)。 仕事のリポジトリでは最近renovateがどんどん導入されているので、これを機にrenovateを導入することにしました。 HugoのバージョンはGitHub ActionsのWorkflowファイル内にenvで指定されていて 、もちろん標準状態のrenovateはこれを検知・更新してくれません。これに対応するには、regexManagers を使用します。 regexManagersは正規表現でバージョン番号を引っかけて更新してくれるmanager で、fileMatchとmatchStringsという二つの正規表現を書くことで使う事ができます。 fileMatchはその名の通り、どのファイルを監視するかを指定する正規表現で、今回はGitHub Actionsの設定ファイルを監視して欲しいので、デフォルトのgithub-actions managerが監視する正規表現をそのままコピーしてきて使用しました。 1 2 3 4 "fileMatch": [ "^(workflow-templates|\.github\/workflows)\/[^/]+\.ya?ml$", "(^|\/)action\.ya?ml$" ] matchStringsはバージョンを引っかけるための正規表現で、datasource、depName、currentValueの三つの値をキャプチャするか、datasourceTemplate、depNameTemplate、currentValueTemplateで値を指定する必要があります。datasource(datasourceTemplate)とdepName(depNameTemplate)はバージョンを比較するためのデータソースと依存の名称で、今回はGitHub上にあるgohugoio/hugoリポジトリのリリースと比較をしたいため、datasourceTemplateにgithub-releasesを、depNameTemplateにgohugoio/hugoを指定しました。currentValue(currentValueTemplate)は現在のバージョン番号を表す値で、これはGitHub Actionsの設定ファイルに書かれている値なので、matchStringsで引っかけてキャプチャします。 1 2 3 4 5 "matchStrings": [ "HUGO_VERSION: (?<currentValue>.*)" ], "datasourceTemplate": "github-releases", "depNameTemplate": "gohugoio/hugo" 設定ファイル全体としては次の様になります: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:base" ], "regexManagers": [ { "fileMatch": [ "^(workflow-templates|\....

2022年9月1日現在、このブログはmarkdownファイルからHugoを使って静的サイトを生成し、GitHub Pagesで公開しています。元々GitHub Pagesにページをデプロイするには、生成済みページを入れた専用のブランチ(一般にgh-pages)を用意するか、生成済みページを入れたディレクトリを用意するか、という二択で、いずれにせよページを生成してから生成されたページをGitHubにpushする必要がありました。前者の場合gh-pagesブランチはmainないしmasterブランチとは一切関係の無いコミット履歴となり、ぱっと見よく分からないですし、後者の場合gitのcommit logにサイト生成のコミットが入ってしまいきれいではありませんし、CIでbuild/pushをしている場合ローカルに毎回pullする必要も発生します。当サイトでもgh-pagesブランチに生成済みページをpushする運用となっていました。 ところが最近、GitHub Actionsから直接GitHub Pagesにページをデプロイできる様になった というではないですか。これは試してみるしかない、ということで設定を変更してみました。 まず、リポジトリのSettings > Pagesから、SourceをGitHub Actionsに変更します。 次に、GitHub Actionsのworkflow設定をactions/starter-workflows を参考に書き換えます。重要なのは2点で、actions/upload-pages-artifactを使って生成済みページをartifactとしてアップロードする点と、actions/deploy-pagesを使ってGitHub Pagesにデプロイをすることです。 1 2 3 4 5 steps: - name: Upload artifact uses: actions/upload-pages-artifact@v1 with: path: ./public 1 2 3 4 5 6 7 8 9 10 11 12 13 # Grant GITHUB_TOKEN the permissions required to make a Pages deployment permissions: pages: write # to deploy to Pages id-token: write # to verify the deployment originates from an appropriate source environment: name: github-pages url: ${{ steps....

皆さん、6月です。6月と言えば、そう、梅の季節ですね。今年も近所の西友で梅やらでかい瓶やらが店頭に並んでいたので買ってきました。このブログでは2020年からしか記録をつけていないのですが、成人してから毎年梅酒と梅シロップを漬けており、梅酒はほぼ手を付けていないので4L瓶が実家にも現在の家にも並んでいます。そろそろ一升瓶を入手して瓶詰めでもしようか、などと考えています。 扨、もちろん今年も梅酒/梅シロップを漬けましたので記録しておきます。今年のレシピはこちらです: 梅: 近所の西友で購入した青梅一袋。多分1kgくらい(で売ってるのが普通のはず？) 砂糖: 西表島産黒糖1kg 酒: ホワイトタカラ 果実酒の季節 1.8L 昨年はかねてからやってみたかった、梅酒用の日本酒を手に入れて日本酒梅酒を漬ける、ということをやりましたので、今年は砂糖の方で変化を入れてみました。酒はこの季節どこにでも売っている果実酒用ホワイトリカーの定番、果実酒の季節です。度数は35%です。適当な焼酎で漬けても良いんですが、黒糖を使うこともあり度数が高めのモノを使った方が良いだろうと考え果実酒の季節を選びました。 梅を洗って、 水分を拭き取りながらへたを取り、砂糖と交互に積み、 酒を注ぎます 余談ですがこの黒糖、カレールゥにしか見えないのは私だけでしょうか 巷にあふれるレシピを見ると、へたのところに水分が残りやすいので注意とか、傷があったらそこから腐るので除けた方が良いとか書いてありますが、多少へたのところに水分が残ってたり傷があっても多分大丈夫です。大きな傷があるモノとか、傷のところが柔らかくなっているモノは除けておきましょう。今回は一袋の内1つだけ傷のところがすこし柔らかかったため除けました。 梅は金気を嫌う、という話が有るので私はへた取りは爪楊枝でやっています。ボウルもプラかなんかの奴で、金属製じゃない奴です。まぁ金属のボウルに入れたところでどれだけ影響があるのか分からないですが。 黒糖特有だと思うんですが、アクのようなモノが浮いてきました。 最後に、瓶に付属していたラベルに年月日とレシピを記録して貼り付けておきます あとはしばらく数日ごとに瓶を揺すって、砂糖が溶けたら放置して3ヶ月くらい経ったら飲むことができます。1年くらい置くとなお良いでしょう。私は永遠に放置します。 続いて梅シロップを漬けます。レシピはこちら: 梅: 近所の西友で購入した青梅一袋。多分1kgだろうという想定。 砂糖: カップ印の三温糖1kg こちらも氷砂糖のレシピが一般的だと思いますが、今年は三温糖にしてみました。店頭で今年は三温糖にしようかな、と思って買ってきたのですが、昨年も三温糖を使ったよう です。まぁ良いでしょう。 酢を入れるレシピもありますが、今年は酢を入れないでやってみることにしました。 以上です。

標題のとおりです。N-ONEを買いました。現行の新型N-ONEではなく、前期型のN-ONEです。グレードはツアラーで、ターボ、パドルシフト、クルーズコントロールなどがついています。納車時走行距離は46,710kmでした。 5月21日(土)に納車、今日車祓をしてもらってきました。 以上。

皆さんはKustomizeのimages transformerは使っていますか？kustomization.yamlに書く、こういうやつです: 1 2 3 4 5 6 7 8 9 10 apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml images: - name: old-image newName: new-image newTag: v1.0.0 kustomization.yamlにこのimages:というブロックを書くと、deployment.yamlでimage: old-imageと書かれている部分がimage: new-image:v1.0.0に置き換えられます。これがimages transformerと呼ばれるもので、kustomizeのドキュメントではImageTagTransformer のところとか、exampleのimages transformer のところとかに説明が書いてあります。 扨、Kubernetesの大きな強みの一つとして、CustomResourceDefinitionを使用して独自のリソースを作成することができる、というものがあります。世の中にはいろいろなOSS CRDがありますが、今回話題にしたいのはDeploymentなどのようにコンテナイメージを指定するタイプのCustomResourceです。例えば、Argo WorkflowsのWorkflowリソースでは次の様にイメージを指定します: 1 2 3 4 5 6 7 8 9 10 apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: batchjob spec: entrypoint: main templates: - name: main container: image: old-image しかしこの場合、kustomization.yamlでイメージを指定しても、old-imageを置き換えてくれません。 が、置き換えて欲しいですよね？ それ、images transformer configurationを書くことで実現できます。 上書きしたいリソースのkindと、イメージを指定するpathを書いた設定ファイルを用意するだけです。この例の場合、kindはWorkflowで、pathはspec/templates/container/imageです。リストのインデックスとかは書く必要は無いです。設定ファイルは次の様になります:...

例えば、はてなブログだとブログカードと呼ばれるこういうの: が有ったり、wordpressだとプラグインでこういうの: が有り、リンクをなんだか良い感じに表示してくれます。このブログでつい先日まで使っていたGhostでも、こういうの: が有りました。 一方、現在使っているHugoには標準機能でこういったものを表示する機能はありません(twitterとかYoutubeはあるんですけど・・・)。しかし、無ければ作れば良いじゃない、ができるのがHugoの良いところです。 Hugoにはshortcode という機能があり、例えば標準のtwitter shortcodeだと、 {{< tweet user="nasa9084" id="1519598305554362370" >}} と書くと 牛乳はさ、牛乳-like飲物よりうまいんだよな — nasa9084@某某某某(0x1e) (@nasa9084) April 28, 2022 の様に展開されます。なので今回は {{< web-embed url="https://example.com" >}} というshortcodeを作ってみようと思います。調べてみると同様の実装をしている人もいましたので、それを参考にしつつ実装していきます。 まず、URLからデータを取得してくるにはHugoのgetJSON を使うと良さそうです。残念ながらOGP情報などを取得する方法は用意されていないようなので、指定したURLからOGP情報をとってきてJSONとして返す様なプロキシ的なサーバが必要そうです。cloud functions for firebase + javascript で実装している人もいれば、Netlify Functions + javascript でやっている人もいるという感じでしたが、やはり個人的にはGoがシュッと読み書きできて早いし、Cloud Functionsなどで常時稼働させておくには認証とかのことも考える必要がありありそう(まぁ無くてもいいっちゃいいけど、よくわからん踏み台にされても面白くない)で面倒だな、ということでちょっと困ったんですが、OGPプロキシサーバは特に状態を持っておらず、hugo buildする間だけ存在してくれればいいので、GitHub Actionsのサービスコンテナとしてプロキシを動かすことにしました。ローカルでテストビルドするときもdocker runすれば良いだけなので簡単です。 ハンドラの実装は次の通りです: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 url := r....

いつの頃からだったか、もう記憶もあやふやではあるけれど、ブログプラットフォームとしてGhost を使っていた。twitter を見る限り、2017年の11月頃には既にGhostを使っていて、確かこの時はDockerでセットアップしていた様な記憶がある。 Ghost、すごい勢いでアップデートされてってて結構アプデが手間 — nasa9084@某某某某(0x1e) (@nasa9084) November 9, 2017 Ghostは結構更新が頻繁で、特にdocker-composeとかも使わずに運用していたので(使っても良かったんだけど、当時はDBもsqliteを使っていてコンテナ一つと永続ボリューム一つ、という単純な構成だったので使わなくて良いか、と思っていた)微妙にイメージの更新が面倒で、container-up というツールを書いてみたりもした。 その後自宅にKubernetesクラスタをセットアップしてKubernetes管理になり、データベースもMySQLに切り替え、最終的にはGCPのfree tierを使ってon VMで運用していた。 Ghostを使い始めた頃はバージョンもまだ1系だったけど、今となっては4系になって、相も変わらず活発に開発され、admin UIも大分変化した。 時代の流れとしては当然といえば当然なのだけれど、Ghost 5.0ではMySQL 8が必須となるということで、最近MySQLの更新をしたところ、頻繁に外形監視がfailする様になった。どうやらリソース不足でレスポンスを返せなくなっていたようだった。free tierのVMなのでe2-microインスタンスを使っているため、さもありなんといった感じ。 もちろん多少のお金を払ってもう少し良いVMにしても良いのだけれど、それほど頻繁に書いているわけでもないブログを運用するためだけに月数千円の出費はいかがなものか、大して書いてもいないのだから静的ページ生成でも良いのではないか、静的ページ生成ならデータベースもいらないしGitHub pagesで配信できて無料ではないか、などと思い、k8s.io でも使っているHugo に乗り換えることにした。 参考にしたのはこのページ 。多少古い記事だけど多少調整すればなんとかなるだろう、と思い見切り発車した。結果なんとか移行はうまくいき、このページが表示されています。 移行手順 まず、ghostToHugo をダウンロードして、Ghostから出力したjsonファイルをHugoにインポート。(ghostToHugoはDarwin_x86_64のバイナリを使ったけど、apple siliconのmacOSでもrosettaで普通に問題無く動いた) 1 $ ./ghostToHugo -p blog.web-apps.tech something-tech.ghost.2022-04-22-02-57-56.json Google Cloud Storageにアップロードしていたバックアップから画像ファイルを取り出してimagesディレクトリに配置した。 1 $ cp ${PATH_TO_BACKUP}/content/images ./blog.web-apps.tech/images イメージのパスをちょっと調整。 1 2 $ find . -name '*.md' | xargs sed -ie 's/__GHOST_URL__//g' $ find . -name '*.md' | xargs sed -ie 's/\/content\/images\//\/images\//g' front-matterをYAMLに変更。 1 2 3 $ cd blog....