検索条件
タグで絞り込み
OS::Linux::Ubuntu(2)
OS::Linux::コマンド(2)
OS::Windows(1)
Webサービス(1)
Webサービス::Value-Domain(1)
ジャンル(1)
ジャンル::ガジェット(1)
全4件
(1/1ページ)
2026/04/10(金)便利なコマンド置き場
投稿日：
特定パス配下のサブフォルダのファイル数を計数して、ソートして列挙する
/path/to/hoge
/path/to/fuga
/path/to/piyo
とあるとして
/path/to/hoge 32
/path/to/piyo 22
/path/to/fuga 4
みたいなのが欲しい場合の方法。フォルダはカウントされないので注意。
サブフォルダの中を再帰的に計測する
for d in /path/to/*/; do printf "%s\t%d\n" "$d" "$(find "$d" -type f | wc -l)"; done | sort -t$'\t' -k2 -nr
サブフォルダの直下のみ計測する
for d in /path/to/*/; do printf "%s\t%d\n" "$d" "$(find "$d" -maxdepth 1 -type f | wc -l)"; done | sort -t$'\t' -k2 -nr
2026/03/31(火)ARM版ノートPCはUbuntuの夢を見ないが、Windowsには光明あり
更新日：
投稿日：
投稿日：
以前、ARMとCore UltraのWindowsノートPCを軽く見て、バッテリー持ちと熱周りを比較してみたところ、かなりいい結果になったのでUbuntuを入れたいが、これができるのかどうかという話。結論から言うと無理らしい。
ラズパイで動くんだから動くんじゃね？と思っていたのだが、そんな都合のいい話はなかった。
x86やAMD64であれば、今時のLinuxは基本的に動作する。これは、これらのアーキテクチャがACPIをサポートしているからだ。ACPIと聞くと自作PC的には電源管理のイメージがあるが、Advanced Configuration and Power Interfaceの略であり、電源だけでなくハードウェアの攻勢も管理できる仕組みになっている。そしてARMにはこれが存在せず、標準化されたハードウェア管理方法がないというわけだ。
ではARMベースのPCではどうしているかというと、今のところOS側でハードウェア情報を持っておき、これを基に起動しているようだ。この情報のことはデバイスツリーと呼ばれているらしい。
例えば、gihyo.jpのそのSnapdragon X搭載PCでUbuntuを使えますか？によると、ARM版UbuntuではSMBIOSというものから端末情報を読み取って、あらかじめUbuntu側で決め打ちしているデバイスツリーを利用してOSを起動するといった手法がとられているようだった。ラズパイの場合も専用イメージがあるため、おそらくデバイスツリーが組み込まれているのだろう。
恐らくこれはARMの場合、基本的にSoCにすべて集約されているため、x86やAMD64のようにメモリやGPUなどが独立したCPUのように管理できないところがあり、ACPIで解決できず、デバイスツリーが必要という事態になっているのだと思われる。
ではWindowsはどうしているかというと、先ほどの記事にもあったがPlatform Extension Plug-ins(PEPs)を使っているとのことだ。これはLinuxでは今のところサポートされておらず、やっているプロジェクトもないようだ。
ならデバイスツリーを書けばよいとも思えてくるが、これは非常に忍耐が必要な作業で、ACPIコードやWindowsドライバのリバースエンジニアリングを行い、カーネルパッケージをビルドし、各ハードウェアが正しく動くかどうかを根気強くテスト、デバッグする作業になるようで、おいそれと気軽にできるものではないらしい。
つまり、ARM版ノートPCでUbuntuを動かすのは、公式にサポートされているもの以外は難しいだろうし、それさえきっちり動く保証はないだろうから今のところ難しそうだ。つまり、ARM版ノートPCを買う場合、重量やキーボードにこだわりのある私の場合、Windowsで運用する必要がありそうだ。何故なら日本のノートPCがサポートされる気がしないからである。
バッテリー持ちがいいのは魅力だが、Windowsにするとなるとメモリやストレージを多めにしないと厳しいので端末価格が上がってしまうのがネックだ。ただソフトウェアの互換性はよくなってきているらしく、出先で使うサブマシンとしてみた場合の実用性は十分にありそうにも思える。
マイクロソフトの案内でも、デバイスドライバやアンチウィルス、アンチチートソフトウェア以外の一般的なアプリケーションは動作するとあるため、この辺りは安心してもよいだろう。一部のソフトウェアの互換性についてはLinaroのWoA対応アプリ検索で確認することができ、例えばXnViewは動作することがわかる。XnVew MPは出てこないが、恐らく動くのではなかろうか？国産のソフトの動作状況はPC Watchの記事でも一部を確認できる。なおエミュレーションで単に動くだけなのか、パフォーマンスがいいかどうかは不明だ。
2026/02/19(木)Value-DomainでcertbotのDNS Challengeをやるスクリプトを書き直した
更新日：
投稿日：
投稿日：
私は2020年の末あたりからLet's EncryptのDNS-01 challengeをValue-Domainで達成するためのスクリプトであるvalue-domain-dns-cert-register (vddcr)の開発を行ってきていたのだが、メンテが辛くなってきたので、今回Shellscript(Bash)Perlでvalue-domain-dns-utilとして作り直した。その経緯と、開発中の学び、そして最後にどうやって作っていったかについて書いていく。
背景
一年半ほど前からTypeScriptに限界を感じてきたことや、当時の誤った単体テストへの偏執により、vddcrはメンテしたくない状態になってしまっていた。
そこで昨夏、つまり2025年の8月に式年遷宮、つまり全体的な書き直しを行ったのだが、個々の処理をする部品を作ったまではいいものの、それらを繋ぎ合わせるところで飽きてしまい、放置していた。vddcrはこの時点で事実上の放棄状態だった。
しかし、自宅サーバーの運用をしていく中で別の目的でValue-DomainのDNS APIと関わらなければならない必要が出てきたため、今回、vddcrの置き換えも兼ねて新しく作り直すことにしたのだ。
具体的には複数ドメインに対するDDNSをバルクでやりたい要求が生まれたが、Value-DomainにあるDDNS APIは一度に1ドメインしか処理できない上にレートリミットが60秒に1回と極めてキツく、複数ドメインに対して行うには余りにも遅延が大きかった。
例えば10ドメイン更新しようとすると10分もかかるわけで、これでは使い物にならないというので、DNS APIを直に叩いて一気に書き換える必要性が出てきたのだ。どうせ作るならvddcrが担っていたDNS challengeの機能も包含できる形にしたかったので、Value-DomainのDNS APIを便利に叩くためのツールキットとしてvalue-domain-dns-utilを作ることにした。
つまりvddcrの純粋な後継ツールというよりは、vddcrの役目もこなせるツールキットを開発し、vddcrと同等の機能を有するツールを実装サンプルとして同梱したわけだ。
Shellscriptにした理由
ものの数時間でPerlに直したので過去の話となった。移植性の関係でbashはイマイチだった。
ぶっちゃけそんなに大した理由はなくて、単に目の前にターミナルとテキストエディタがあってパッと組めたからという部分が大きい。実際ベースはパッと作れた。まぁ作って半年も放置していたのが…。ただまぁPerlの方が保守性は高いだろうし、移植性もあるだろうとは思うから、気が向いたら書き直すかもしれない。
ちなみに別言語に移植することの検討はvddcrでも行っていたが、最終的には候補になかったShellscript(Bash)での実装に落ち着いた。そもそもこの課題の存在を忘れていたので、検討すらしていなかったのである。
value-domain-dns-utilについて
今回作ったvalue-domain-dns-utilは、vddcrの単純な代替ではなく、Value-DomainのDNS APIを叩くのに便利なShellscriptの関数群だ。DNS challenge以外にも用が生まれたので、このような汎用的な形になっている。
DNS APIから現在のレコードを取得する関数や、取得したレコードから先頭一致のパターンマッチでレコードを取得する関数、レコードリストへの追加や置換をする関数、そして編集したレコードをDNS APIに送り戻す関数を備えており、DNSに関する一連の編集処理ができるように便利に作っている。
結果として、Value-DomainのDNS APIを叩く汎用機能があれば、それを流用してLet's EncryptのDNS-01 challengeもできるし、当然複数ドメインに対するDDNSをバルクでやることも可能になる。
学び
開発中に発見も多くあったので記していく。なんかこういうのまとめた記事かページ作りたいね。
echoでドルマーク始まりのシングルクォート文字列を作ると、その中の改行コードが展開される
例えば以下のようになる。これは一行で改行展開を書けて変数に入れられるので、インデントされているコードなどで物理的にへし折りたくないときなどに有用だし、文字列としてのコードが見えるのでわかりやすい部分もあると思う。
入力
#!/bin/bash
# ドルマーク始まりのシングルクォート文字列は改行が展開される
echo $'1:aaa\nbbb'
# つまりこれと同じ
echo "2:ccc
ddd"
# ダブルクォートの中の\nは展開されない
echo "3:eee\nfff"
# ドルマーク始まりのダブルクォートも展開されない
echo $"4:ggg\nhhh"
# 一行で改行展開を書けて変数に入れられるので便利
hoge=$(echo $'5:iii\njjj')
echo "$hoge"
出力
1:aaa
bbb
2:ccc
ddd
3:eee\nfff
4:ggg\nhhh
5:iii
jjj
変数の最後の一文字を削る
これは後方一致除去（${parameter%word}）と呼ばれるものらしく、詳しくは調べていないが"hoge"に対してfugaを繋げ、"hogefuga"としたい場合に便利だ。
例えば以下のように書ける。
入力
#!/bin/bash
hoge='"hoge"'
fuga='fuga'
result="${hoge%?}$fuga"'"'
echo $result
出力
"hogefuga"
sedで改行を改行コードに置換（\n→\\n）
これは見つけた当時sedの記事にも書いているが、以下のようになる。
入力
cat <<'EOF' | sed ':a;N;$!ba;s/\n/\\n/g'
aaa
bbb
ccc
ddd
EOF
出力
aaa\nbbb\nccc\nddd
[]ではGlob展開できないが、[[]]では出来る
今のところこういった形式でGlobを書くことはないのだが、Sonnet 4.6にテストコードを書かせている中で発見したので書き留めておく。
入力
#!/bin/bash
hoge='aaabbbccc'
[ $hoge = *"bbb"* ]
result1=$?
[[ $hoge = *"bbb"* ]]
result2=$?
echo $result1
echo $result2
出力
1
0
あとがき
LLMとの作業分担
今回の開発でもLLMを活用したのでその辺り。
今回の開発では、8ada152～93d58ccのコミットを行った。最も古いコミットである8ada152ではテストコードを除き、私がフルスクラッチで書き、テストコードはClaude Code(Sonnet 4.6)に書かせた。
次の029a951では、私が書いたコードをClaude Code(Sonnet 4.6)に全体的に直してもらって私がレビュー・微修正するという開発形態をとった。それ以降のコミットはコメントなどの微修正なので、再び私が手動で書いている。
こうした分担により、設計の根底にある信条のようなものには私の色が濃く出ているが、実装上の問題点はClaude Codeによって大きく改善されている。特に029a951では、typoや単純な実装ミスの修正に加えて、bashの文字列処理に不慣れなことで生まれたエスケープシーケンスの山が整理された。jqの-rオプションの有無がまちまちだった部分も統一され、可読性がだいぶ向上したと思う。
とはいえ、Claude Codeの言うことを鵜呑みにはしていない。こちらから明示的に指示して直させた箇所もある。例えばテストコードのappend_recordやreplace_recordのアサートは元々Globで書かれていたのだが、より厳密にするために全文マッチに直させた。別にレコードの順序がどうなっていようとValue-Domain APIは気にしないどころか勝手にソートされるので実用上の意味はないのだが、こういうのは人としての拘りである。
昨今は過去の記事でもちょいちょい言及している通り、LLMを使った開発をそこそこしていて徐々に馴染めてきているので、その点も含めてよい経験になった。
抽象化した今回の設計と、過去の歪な設計を振り返って
抽象化して再利用性を高めた今回のツールキット方式と、単体テスト大正義とばかりに変な作りになってしまった前回の方式の振り返り。
過去のvddcrでは単体テストへの誤った偏執によりモジュールが具象的な単位で分割され、非常にメンテナンス性が悪く、再利用性もないものになっていたが、今回はちゃんと抽象化して、責務ごとに機能が切れたと思っている。このことによって再利用性が高く、使いやすいものが作れたと考えている。大した規模ではないとはいえ、部品を組み合わせて処理を組むには程よくいい感じだろう。
先ほどのことや、単純に機能を削ったこと、TypeScriptの複雑すぎる型管理や非同期処理から解放されたこともあり、コードもだいぶ見通しがすっきりした。ツールではなく、ツールキットという形で作ったことも奏功し、Value-DomainのDNS API周りのスクリプトは大分作りやすくなったと思う。将来的にバルクのDDNSスクリプトを書くのも楽になるはずだし、重い腰を上げて作れてよかった。
式年遷宮で起きる変遷について
式年遷宮をする以上、元の状態には戻れないという話があり、それが何故起きるのかみたいなところが分ったような、分からないような、そんな話。
しかし世の中には式年遷宮で全く違う姿になるものがある。今回作ったのはまさにそんな感じで、なんというか作者の気持ちがわかった気がする。
分かりづらい例えだが、FF14の外部ツールであるConcept Matrix(CMTool)がAnamnesisに変わったときは、全く別物になった気さえしたし、こういった式年遷宮によって元あったことは一応できるにはできるけど、複雑になったり、なんかかゆいところに手が届かなくなったり…みたいなのは他でもちょいちょいあると思っていて、今回vddcrをvalue-domain-dns-utilにしたのもまさにそうだと思う。
という背景があるのもあり、完全互換を目指したvd-dcr.shを同梱することで、この不便さを少しはなくそうとした。いやまぁ自分のためにやってるので、自分のためのことではあるのだが…。とはいえ、以前のと比べるとプラットフォーム別の互換性は落ちていると思うので、現時点だと動かない環境は増えている気がする。
あとがき2：結局Perlに変えた
動かそうとしてた環境の一つのシェルがashで、bashが使えないことに気が付いたのでSonnet 4.6に頼んでサッとPerlに変えてもらった。
