低温調理器で足湯作った♨️

低温調理器足湯 with バスラボ（入浴剤）

家が寒いので、メルカリで低温調理器を買って足湯を作りました。

（この記事を参考に足湯を作った結果何らかの損害を被ったとしても、当方では責任を負えません。ご注意下さい）

TL;DR

• 低温調理器と収納ボックスを組み合わせて足湯を作った
• 市販のフットバスよりも広くて気分が良いが、注意点もある
• 入浴剤を入れてアロマ代わりにしたり、部屋の乾燥を防いだりと応用も効く

動機

築60年弱の木造住宅に住んでいるため、断熱性が低いのを悩んでいました。

そこで思いついたのが足湯の自作です。低温調理器で足湯を作る挑戦については、すでにデイリーポータルZに先駆者の方のブログがありました。

dailyportalz.jp

しかしデイリーポータルZの記事の方はやってみた感が強く、マジで凍えている私とは切実さが違います。普段使いにすることで生まれる新規性もあるだろう、と思いチャレンジすることにしました。

製作にあたって（あれ、これ売れるんじゃね？）と思いましたが、ググるとすでに商品がありました。いっそ購入も考えましたが、足の可動域が少なそうだったので好みに合わず、お見送りに。

仕様

低温調理器と収納ボックスの2つの部品からなります。2つ合わせて6,700円ほどでした。

低温調理器

価格・最低水位・取り付け方の観点から、サンコーの低温調理器を選定しメルカリで調達しました。

簡単に低温調理ができる「マスタースロークッカー」 SOVDCOOK ※日本語マニュアル付き サンコーレアモノショップ

価格は当然として、最低水位と取り付け方がポイントです。

低温調理器は、鍋の水位が最低水位を下回っている場合には動作しないようになっています。足を入れる場合は鍋ではなく広くて浅い容器を使うことになるので、なるべく浅くても動作すると使いやすいです。機種によっては20cm程度を要求することもありますが、10cm以下のモデルを選びたいところです。

取り付け方もポイントです。容器との兼ね合いですが、収納ボックスのフチは鍋のように薄くありません。したがって、クリップの可動域が広そうな機種がオススメです。

収納ボックス

穴がないこと・フチの薄さ・高さの観点から、アステージの収納ボックス（高さ16cm）を選定しました。

JEJアステージ 収納ボックス 日本製 NCボックス #13 積み重ね [幅29.5×奥行44×高さ16cm]

収納ボックスは普通液体を入れるために作られていないと思うので、ホームセンターでなるべくプロ向け・釣りにも使いそうなものを選びました。

フチの薄さも重要だと考えています。フチが余りに厚いと、低温調理器のクリップ部分で挟めない or 可動域が常に全開になってしまう（バネが伸びてしまう）恐れがあると考えました。

また、高さがあると低温調理器の最低水位に達するまでにかなり水を入れる必要があります。コスパよく使うため、ちょうどよい高さの物を選びました。

製作にあたって

上記の組み合わせを発見するために、2回ほどプロトタイプを作成しています。

1度目のプロトタイプでは100均のタライでやってみましたが、すぐに低温調理器が自立しないことに気づきました。

低温調理器足湯 プロトタイプ1

幸い足を突っ込んだ感じは良好だったので、容器を変えて続行することに。

低温調理器足湯 プロトタイプ1 足加減良好

プロトタイプ2では家にあったツールボックスでやってみましたが、高さがあったために最低水位を満たすまでかなり水を入れました。これは水道代が心配ということで、本使用では別の箱を購入することに。また、高さがあると低温調理器自体の重さで箱が傾かないかも心配でした。

低温調理器足湯 プロトタイプ2

使用した感想

すでに3ヶ月ほど使っていますが、基本的に満足しています。寒い日でかつリモート勤務の日は必ずといっていいほど使用しています。

水はだいたい2,3日に1度変えています。小さくてもお風呂なので、お湯が濁ってくるためです。

それ以外に、水が蒸発するので毎日継ぎ足しています。容器を水道まで持っていくのは重い＆バランスが悪くて大変なので、バケツなどで水を注げるといいですね。

利用していると、気のせいかも知れませんが部屋の乾燥が和らぐ気がします。我が家はエアコン使用時に洗濯したジーンズが3時間でほぼ乾くほど乾燥しているので、とてもありがたいです。

最近では入浴剤も利用してみました。低温調理器の寿命を縮める可能性があるのでオススメはしませんが、部屋の中がいい匂いで満たされるので気分は良いです。

低温調理器足湯 入浴剤

注意点

調理器具なので、操作を誤ると普通に60度以上になって危険です。

また、当然ですがメーカーの保証範囲外・非推奨の利用方法です。なにか問題が起きても自己責任なので、ご注意下さい。

今後の展望

入浴剤をアロマ代わりにする可能性をもっと探求していきたいです。匂いがよく、薬効もあり、かつ少量から使えるようなものを探していきたいです。

まとめ

低温調理器で自分だけの足湯ができ、満足しています。他にやってみたい方の参考になれば幸いですが、くれぐれも自己責任でお願いします。

書評 - MaxOS X ターミナルコマンド ポケットリファレンス

defaultsコマンドへの興味が高じて、2000年代の海上忍さんのOS Xに関する著書を読んでいます。

amzn.to

TL;DR

• OS Xのターミナルで利用できるコマンドを抜粋して解説
• 用途ごとに章立てされており、全300ページ程度
• macOS 11では利用できないものも見られるが、知らないものも多く読んでよかった

特に気になったコマンド

nano

2,3年前くらいからシステムのデフォルトエディタになっていることがちらほらあり、てっきり新しいエディタなのかと思っていました。

実際にはOS Xの初期から pico（ nano のインスパイア元）が搭載されるなど、歴史のあるエディタのようです。

type

シェルのビルトインコマンド。debianにもBSDにもあるので割と有名なようだけど、初めて知りました。

which をエイリアスに対して実行する場合は終了コード1が返ってくるが、type の場合はaliasであることを教えてくれるので便利。

root@fe314f058bb4:/# alias foo="echo foo"
root@fe314f058bb4:/# foo
foo
root@fe314f058bb4:/# which foo
root@fe314f058bb4:/# echo $?
1
root@fe314f058bb4:/# type foo
foo is aliased to `echo foo'

appleping, atlookup

AppleTalkがサポートされなくなったことに伴い、コマンド自体も無くなっていました。 最新のmacOSでAppleTalkを有効にする方法はちょっと分からなかったので、古いOS XやNEXTSTEPエミュレーターに触る機会があれば試してみたいです。

nvram

macOSの調子が悪くなったときにやる NVRAMリセットでおなじみ、NVRAMに設定されている環境変数を見ることができます。

正直中身は一切わからないものの、Intel MacとM1 Macで違うのかな？というのは気になりました。

まとめ

リファレンスを読むことで知識の隙間を補完できました。

ProxmoxのWeb画面で This page isn’t working と表示される → httpではなくhttps を使っていますか？

TL;DR

ProxmoxはデフォルトではHTTPでのリクエストをHTTPSにリダイレクトしないため、管理画面にHTTPでアクセスすることはできません。

Proxmox - This page isn’t working

This site can’t be reached との違い

ブラウザのインスペクターでTiming breakdown を見ると分かります。

This site can’t be reachedの場合、リクエストがStalledになっていますが、

This site can’t be reached の場合のTiming

This page isn’t working の場合、Initial Connectionまでは進んでいます。つまり、IPレベルでは疎通できており、TCPレベルでのやり取りが始まっているということですね。

This page isn’t working の場合の Timing breakdown

せっかくなのでWiresharkでパケットも見てみました。

This site can’t be reached の場合、TCP Handshakeでお断りされていることが分かります。

This site can’t be reached のパケット

This page isn’t working の場合、TCP Handshakeは成功しています。

This page isn’t working の場合のパケット

ただし、HTTPを送るやいなや会話を打ち切られるかのようにFINパケットが飛んできます。この辺もうちょっと勉強したいところ

This page isn’t workingのFINのパケット

補足

Proxmoxにnginxをインストールしてリダイレクトする、という方法もあります。

pve.proxmox.com

まとめ

ChromeのTime breakdownを活用して管理画面にアクセスできない原因が分かりました。

書評 - 図解で明解 MacOS Xのしくみ

defaultsコマンドについて調べているうちに、NeXTSTEP時代からのユーザーがMac OS Xをどう思っているかをぜひ知りたくなって購入、通読しました。

amzn.to

著者の海上忍さんは、マイナビニュースで OS Xハッキング! という連載をお持ちだった方です。defaultsコマンドの隠しオプションを探す記事があまりにも面白く、Amazonで著者名で検索して手頃な価格の本書を購入した...というわけです。

news.mynavi.jp

感想が多くなるので、本書について触れた後、特に気になった前半について章ごとに述べます。

本書について

表紙に「Aquaを超えて。」とあるように、GUIだけでは分からないOS Xの魅力を語っている本です。要するに開発者かオタク向けの本と言っていいと思います。

著者は単にMac OS Xに詳しい人というわけではなく、BSDの特徴やNeXTSTEP（Amazonの著書を見る限りはBeOS）など、コンピューターが本当にお好きな方だと推察します。

図解と言っても昨今よくある操作のスクショを貼って水増しした本ではなく、OSの起動の仕組みやDarwinの仕組み、OS Xに連なるOSの系譜などの概念図が盛りだくさんです。しかも全部で300ページ以上あり、それでいて発売時の値段は2,000円弱というカルピスの原液を煮詰めたような本です。

もちろんスクショもあるのですが、それにしてもNeXTSTEPやOS X Serverのスクショなど、本当にコンピューターが好きでないと撮れないスクショが多くて驚きました。

MacOS Xの基本

この本を通読して思いましたが、OSを知るには意識高くOSを自作するより手元のmacOSを徹底的に知ったほうが近道だと思います。そうした要求に応えてくれる章でした。 また、全体を通してMac OX 9以前との比較で書かれている点が興味深いです。

ホームフォルダとマルチユーザーに関する解説は、これまで業務でLinuxを触ってきてなんとなく分かっていたものが他人の言葉で整理された感じでありがたかったです。特に「職場や学校など大人数が1台のコンピュータを共有することを前提として」UNIXがマルチユーザーのモードを備えていたことは納得がいきました。同時に、マルチユーザーが前提ではなかった（と推測される）OS 9以前に思いを馳せて、現代の当たり前にも歴史があるのだと思いました。

2003年の本ということもあり、当時のOS X（10.2 Jaguar）と私が使っているmacOS（11.5.2 Big Sur）だと違う点もあります。

例えばシステム起動時の舞台裏として解説されている、Open Firmawreから起動される /System/Library/CoreServices/BootX ）は 、Big Surでは（歴史的には OS X 10.6から） /System/Library/CoreServices/boot.efi に取って代わられています（というか BootXというのは PowerMac の場合のファイル名かもしれません。要調査）

en.wikipedia.org

その後に起動する initは launchd に取って代わられているし、 /etc/rc は /etc/rc.common と /etc/rc.netboot に変わられているようです。

www.itmedia.co.jp

しかし、本質的な理解に障るほどではないし、現代のmacOSについてここまで解説した本があるのかも疑問なので、やはり有り難いと思って読んでいます。

（Oreillyの Running Mac OS Xは同様の本かもしれません。今度読んでみます）

amzn.to

その他の箇所でいうと、仮想メモリが常に有効なこと（そういえばmacOSでWindowsみたいなデフラグをしたこと無いな）、OS 9以前はApple Talkが基本だったこと（TCP/IPじゃない低レイヤーが想像つかない...）も興味深かったです。

MacOS Xの基礎技術

macOS...というかDarwinがハイブリッドカーネルで、MachとBSDの系譜である...というのがイマイチ分かっていなかったのですが、本章で少し理解が進みました。

DarwinがBSDの系譜であるというのには2つの意味がありそうです。まずDarwinのカーネルであるXNUがMachとBSDの両方の特徴を併せ持つということ。次に、ユーザー向けシェルやコマンドはBSDから移植したものが多いこと 。とはいえ以下にツイートしたとおり全然分かっていないので勉強を勧めたい所存です（そろそろmacOSアプリ作るなりDarwin動かすなりしたほうが早いかも）

XNUに関する文章を書こうとしてたんだけど全然理解できてないことに気づいてしまった。多分こんな感じ...? pic.twitter.com/7CaFmHAQSr

— さわら (@xhiroga) 2021年12月29日

実は、 defaults コマンド（そして前身の dread, dwrite, dremove ）の由来がBSDではないか？と疑っていたのですが、今回調べておそらく違うという思いを強めました。 （defaultsコマンドはプロパティリストを編集するコマンドだが、プロパティリストはCoreFoundationのオブジェクトであり、それはNeXTのカーネル部分というよりは開発者向けキットが由来のため）（なのでどちらかというとSmallTalkに源流がある気がしないでもない。要調査）

実行可能なバイナリに旧Mac OS用とOS X用の違いがあることを初めて知りました。MacOS 9以前との後方互換性を一応保とうとしていることが伺えるのも面白かったです。

これに関連して、手元のBig Surのアプリケーションのバイナリ形式を見てみたら Mach-O で、歴史を感じて嬉しくなりました。

こんなところに Mach の名前が残っており歴史を感じる。 pic.twitter.com/vP2BUdqask

— さわら (@xhiroga) 2021年12月29日

他、ルートディレクトリに関する解説もためになりました。そういえばLinuxも体系的に学んだことが無い気がするのですが、これを気に学んでもいいかもしれません（Dockerfileでバイナリをどこに配置するか、とかで悩んでしまうので）

BSDとしてのMaxOS X

この章ではBig Surとの違いが面白かったです。

一番衝撃を受けたのはリソースフォークです。Apple独自のファイル形式（ファイル内にメタデータの領域を持つ。リソースフォークはメタデータ領域の名前）があるのは不思議ではないですが、それにしても互換性がなさすぎる...と思いました。ちゃんと廃れたようで良かったです。

他、基本のシェルが tcsh だったことも驚きました。私が OS Xを使い始めた頃にはすでに bash で、現在は zsh なので、2回も変わっていて驚きです。

まとめ

macOSの歴史を知りたい私にピッタリの本でした。知れば知るほど知らないことが増えていく感じがするので、自分のペースで本やソースを読んでいきたいなぁ、と思います。

書評 - 実践 CSIRTプレイブック

会社でプロダクト横断的な業務が増えてきたこともあり、SREチームで読み合わせました。

実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

TL;DR

• 複数のプロダクトを持つ企業の現場担当者向けに書かれた本
• プレイブックの考え方は、アプリケーション開発チームとは異なり勉強になった

本書について

CSIRTってなんだろう？と気になったので読んだ本。

勤務先はまだアプリケーション開発者がSREとセキュリティエンジニアを兼ねているような状態なので、CSICOの取り組み自体は正直あまりピンとこない箇所もあった。

Yahoo!JapanやDeNAなどの大企業のセキュリティ担当者に転生したら...と想像しながら読むと面白いかもしれない。

プレイブックの考え方

スタートアップでセキュリティを意識するにあたって、以下の点が気になっていた。

• アプリケーション開発のためのアプローチ（スクラム・ウォーターフォールなど）はセキュリティにおいても有効なのか？
• トイルをなくすにはどうしたらいいか？

プレイブックはそうした問題への解決策だった。すなわち、

• イベント駆動型で機能する組織にする。問題発生時にプレイブックを用いて分析する（つまり手順書）
• プレイブックにクエリなどを埋め込み、日々改善を重ねる

本書の後半には具体的なクエリまで紹介されていて、実感が湧いた。ただ、小規模な組織なら実務ではAmazon GuardDutyのようなベンダー提供のルールセット（または機械学習）を使うほうが現実的かもしれない。

まとめ

チームの運営モデルとしてプレイブックを知ることができたのは有益でした。自分たちの組織に合わせてマネージドサービスを使って運用をカスタムしていければいいのかな、と思います。

書評 - CSIRT 構築から運用まで

SREチームとしてプロダクト横断的な仕事が増えるに従って、CSIRTを参考にしようと思って手にとった本の一冊です。

CSIRT

TL;DR

• どちらかというと大企業の役員・部長クラス向けに書かれている本
• 運用における対外連携は規模に関わらずあり得る、参考になった
• ケーススタディが具体的で参考になった。もっとあっても良い

本書について

NTT関連会社に勤めるセキュリティ関係者が書いた本です。他の方のレビューにもありましたが、教科書的な印象があります。

セキュリティインシデントの分類はありがたいのですが、やや古い上に粒度が揃っていない印象を受けました。

2021年現在、JPCERT/CCの分類で用いられているのは以下の7種類です。

• フィッシングサイト
• Webサイト改ざん
• マルウェアサイト
• スキャン
• DoS/DDoS
• 制御システム関連インシデント
• 標的型攻撃
• その他

しかし、分類方法に攻撃手法と攻撃対象の2軸があることが気になります。また、エディタやライブラリの汚染、SaaSの脆弱性によるトークンの窃取などをどこに分類するか（マルウェアサイト？）も疑問が残ると思いました。オンプレで開発・運用が完結する業界ならこれでいいのかもしれません。

インシデント発生時の対外連携

スタートアップの規模でゼロデイや日本初の脆弱性を突かれるケース、あるいはフィッシングサイトを作られるケースは多くないのかな？と考えています。

（もっとも、暗号資産の取引所はガンガン攻撃されていそうですが）

特にフィッシングサイトが海外に建てられているようなケースは、言われてみればどうやって対応するのか分かりませんでした。本書を読み、フィッシング対策協議会やJPCERT/CCに相談して停止を調整すればいいことが分かりました。

ケーススタディ

セキュリティインシデント発生時の組織内でのシーケンス図が載っており、対応の実感がわきました。

2016年の本にも拘らずランサムウェア感染時のケーススタディが載っているのは先進的かもしれないです。

それまではセキュリティインシデント発生時の対応といっても（アプリケーションチームが主役なのでは？）という感じでしたが、たしかに脆弱性やアクセスログの横串調査は誰かが旗を振らないと難しいな、と思った次第です。

まとめ

やや古い感はありましたが、特に対外組織との連携など会社の規模が大きくなったときに発生するプロセスを知ることができたので良かったです。

RSSリーダーと「後で読む」の再選定 (2012)

TL;DR

RSSリーダーおよび「後で読む」として、Inoreaderを選定しました。

Inoreader

動機

勤務先のjustinCaseで、SREのメンバーと #justInCaseWeeklySRE を始めました。先輩の @laplace1984 さんの情報量が圧倒的なので、これは負けてられないと思い体制を整えています。

また、Log4Jの脆弱性についてTwitterで知ったことにも不安を覚えました。もしTwitterで知らなかったら...と思うと怖いので、JPCERT/CCを正しく購読しようと思ったのです。

比較表

FeedlyとInoreaderを比較しました。

	Feedly	Inoreader
Initial Release	2008	2013
❤️ at alternative.io (2012-12-26)	❤️1805	❤️1393
AppStore Rating	⭐️4.6 (7643)	⭐️4.5 (3631)
Read it later from Chrome	Offical: 🙅‍♂️	🤔（Webページの保存は可能だが、後で読むへの追加は不可能）
Read it later from iOS app	🙆‍♂️	🤔（Webページの保存は可能だが、後で読むへの追加は不可能）
Subscribe without RSS	🙆‍♂️	🙆‍♂️
Idempotent import	🙆‍♂️	🙆‍♂️
Googleアラート	$12で購読可能	無料で購読可能
Auto mark as read	30日	30日
Feed limit of free plan	100	150

大差はないものの、Googleアラートが無料で購読可能なこと、いくつかブログを読んでFeedly → Inforeaderへの乗り換えが多く見られたことなどから選定しています。

後で読む機能が無い点のみ惜しいのですが、Webページの保存機能を代わりに使うことにしました。それによって、Pocketを廃止してツールをまとめられるのも嬉しいです。

まとめ

ニュースを確実にインプットしつつ、実質ゴミ箱だった「あとで読む」もうまく運用できることを期待しています。