こたつとコード

エンジニアの読書手帖

家の J:COM Wi-Fi 不調を調べる中で学んだ、自宅ネットワーク環境の基本的な用語や違い

技術

家では J:COM を使用している。基本的に Wi-Fi は問題なく使えているのだが、時々不安定になることがあった。 光回線にしたらいいとか有線にしたら良いとかは聞くが、そもそも Wi-Fi との違いもわかっていないので用語を含めて調べてみることにした。

計測

家の Wi-Fi 不調を調べるため、まずは速度を測定できるサイトを試した。今回 Speedtest by Ookla を使用したが、他にも色々あるらしい。

計測の結果と用語

実際に実行した結果は次のとおり

speedtest

この結果で出てくる用語を整理しておこう。*1

Download(下り速度)

インターネット上からデータを受け取る速さが Download。単位は Mbps。動画視聴や Web 閲覧は Download が重要になる。

Upload(上り速度)

インターネットにデータを送信する速さが Upload。こちらも単位は Mbps。ビデオ会議で映像を送ったりファイルをアップロードするのは Upload に依存する

Ping(レイテンシー)

Ping は回線の応答時間。自分の端末からサーバーまでパケットを送って戻ってくるまでの往復時間で、単位はミリ秒(ms)。ネットワークの反応の速さを表す。20 ms 以下が良好、50 ms あたりまでは問題なし、100 ms を超えると遅延を体感する、というのが目安らしい。

Download/Upload (Mbps) は流れの太さ、Ping は反応の速さ。動画を見るだけなら太さが大事だが、ビデオ会議やゲームでは反応の速さの方が体感を決める。

Jitter

Jitter は Ping のばらつきを表す。「20, 21, 19, 22, 20 ms」なら Jitter は小さく、「20, 287, 22, 412, 25 ms」なら平均は近くても Jitter は大きい。平均値が良くても Jitter が大きいと、ビデオ会議やゲームで「途切れた」「ラグった」という体感に直結する。「不安定」という体感は、平均速度ではなく Jitter として現れていることが多いらしい。


有線接続

有線接続と無線接続の結果差

ある日、Wi-Fiの調子がかなり悪かったタイミングで、無線と有線での結果を比較したところ、次のようになった。

項目 無線 有線 差分
ダウンロード速度 2.16 Mbps 753.76 Mbps +751.60 Mbps
アップロード速度 29.87 Mbps 95.95 Mbps +66.08 Mbps
PING アイドル 33 ms (低26 / 高26, Jitter 238) 20 ms (低14 / 高14, Jitter 4) -13 ms
PING ダウンロード時 157 ms (低26 / 高2111) 86 ms (低14 / 高142) -71 ms
PING アップロード時 30 ms (低17 / 高491) 24 ms (低10 / 高265) -6 ms

ここから、回線自体に問題があるのではなくて、Wi-Fiに問題があることがわかった。

無線通信は本質的に不安定で、近隣 Wi-Fi との干渉、壁による減衰、機器との距離など外的要因の影響を受ける。有線はケーブル内を物理的に信号が通るので、これらの影響を受けにくい。実際、今回のパターンで、無線はかなり調子が悪くなったが、有線は特に影響が出ていなかった。

「Wi-Fi が不安定」と感じたとき、まず有線で計れば、回線そのものの問題なのか Wi-Fi 区間の問題なのかが切り分けられる。 ちなみにこの日は一日中調子が悪かったのだが、モデムを再起動することで改善された。

通常時の差

項目 無線 有線 差分
ダウンロード速度 347.04 Mbps 777.36 Mbps +430.32 Mbps
アップロード速度 97.52 Mbps 89.9 Mbps -7.62 Mbps
PING アイドル 28 ms (低18 / 高18, Jitter 3) 29 ms (低18 / 高18, Jitter 9) +1 ms
PING ダウンロード時 65 ms (低18 / 高624) 72 ms (低18 / 高158) +7 ms
PING アップロード時 35 ms (低15 / 高262) 30 ms (低15 / 高261) -5 ms

無線の調子が悪くない日でも差を調べた。ダウンロード速度でも差は出ていたが、無線でもそこまで遅い速度ではなかった。特に差が出ていたのはダウンロード/アップロードの Ping の値で、通信の安定性が改善されていることがわかる。

J:COM のモデム

家のインターネットは J:COM の契約で、CATV (ケーブルテレビ) と同じ同軸ケーブルでインターネットを提供する方式だった。CATV の契約で家に設置されるのが モデム と呼ばれる機器で、信号を変換する役割を持つ。

家にあったのは KCM3101 という機種で、これは「モデム + ルーター + Wi-Fi アクセスポイント」が一体になった機器だった。「J:COM のモデム」と呼んでいるものは、実際にはそれだけではない。家庭向けの機器は次のように分類できる。

  • モデム単体: 信号変換だけ。ルーターを別途用意
  • ルーター単体: ネットワーク管理と Wi-Fi。モデムや ONU と組み合わせ
  • 一体型: 上記がひとつに収まったもの

なお、光回線では「ONU (Optical Network Unit)」がモデムに相当する。

有線接続する方法

ネットワーク機器の背面を見るまで、自分はインターネットへの接続を Wi-Fi 経由でしか体験したことがなかった。

モデムの背面画像

KCM3101 の背面には Ethernet (LAN) ポートが 4 つ並んでいる。ここにケーブルを挿せば有線接続になる（知らなかった）。Wi-Fi 機能とは独立しているので、Wi-Fi が不調でも有線ポートは普通に動く。

有線LANの規格

LAN には規格 (カテゴリ) があり、家にあったLANコンセントは「Cat5e」だった（設置されていたコンセントに書いてあった）。Cat5e は 1 Gbps 対応で一般家庭の標準。家庭の回線速度であれば十分だ。

規格 最大速度 最大周波数 用途・特徴
Cat5 100 Mbps 100 MHz 旧規格、ほぼ非対応
Cat5e 1 Gbps 100 MHz 一般家庭の標準
Cat6 1 Gbps (10 Gbps は 55 m まで) 250 MHz 現在の主流。家庭向けとしてもおすすめ
Cat6A 10 Gbps 500 MHz 家庭向けとしてもおすすめ
Cat7 10 Gbps 600 MHz 業務用
Cat7A 10 Gbps 1000 MHz 業務用
Cat8 40 Gbps 2000 MHz 業務用

*2 *3

家にあったLANコンセントは「Cat5e」だったが、互換性があったため有線LANは「Cat6A」のものを購入した。

amzn.asia


回線の種類

結局、回線の違いは何か。主な回線の種類を整理しておく。

項目 CATV 光回線 モバイル回線
媒体 同軸ケーブル (テレビと同じ) 光ファイバー 電波 (4G/5G)、SIM
上り下り 上りが下りより細い 対称または準対称 上りが下りより細い
安定性 地域内で帯域共有、混みやすい ノイズに強く安定 電波状況・混雑に依存、場所により不安定
契約 マンション一括が多い 個別契約が基本 個別契約 (SIM)
代表例 J:COM フレッツ光、auひかり、NURO 光など WiMAX、各社モバイル Wi-Fi ルーター

*4

同軸ケーブルは「電気信号」を運び、光ファイバーは「光の点滅」を運ぶ。長距離や高周波数での減衰やノイズの影響が違うので、安定性に差が出るらしい。

おわりに

Wi-Fi の不調自体は、有線LANを使用するというシンプルな対応で終わった。最初は光回線の導入を検討していたが、光回線の方が良いのは間違いなさそうだが、今回のようにそもそも回線を繋いだ以降のルーター部分やWi-Fiの環境部分で問題なこともある。その場合は有線接続などを行えば解決されることがわかったので、ゲームなどを行うわけではない私には光回線は不要だった。

*1:https://www.speedtest.net/ja/about/knowledge/glossary

*2:https://www.sanwa.co.jp/seihin_joho/lan_category/index.html

*3:https://www.panduit.co.jp/column/naruhodo/6142/

*4:https://www.gate02.ne.jp/media/it/column_141/

言語化と飛躍に関しての雑記 - 海辺のカフカの一文とアブダクション

雑記

彼女はおそらく意味や論理といった冗長な手続きをパスして、そこにあるべき正しい言葉を手に入れることができたんだ。宙を飛んでいる蝶々の羽をやさしくつまんで捕まえるみたいに、夢の中で言葉をとらえるんだ。芸術家とは、冗長性を回避する資格を持つ人々のことだ。*1

この一文が好きだ。

少し前に有名だからという理由だけで手に取った『海辺のカフカ』を読んで、この一文だけがずっと頭に残っている。これは大島さんが主人公に対して放った言葉だが、この文章に触れた時に、芸術に疎いくせにとても納得したことを覚えている。

ある言葉や表現に対して、妙にしっくりきたり、好きだと感じたりする。ただ、そこにはその感覚になった理由や意味がない。この文章はそういった状況をあらわしてくれている文章に感じた。この文章に対してもまさに同じで「なんだかしっくりきた」以上の感想が出てこなかった。

私はこの文章に何を感じて頭に残ったのだろう。



仕事をしていると「言語化していこう」みたいな話があがったりする。この人は言語化がうまいよね、みたいな話もでるし、一年の目標に「言語化」をあげている方もいる。

言語化は大事だ。ただ、言語化することだっていいことばかりではない。

例えば、好きなものに対して理由をつけることで陳腐化することはよくある。なぜ好きなのかを他の人に説明しているうちに、うまく説明できなさすぎたり、思ったより口から出てきた言葉が貧相で、少し悲しくなることだってある。

私は、この言葉が狭くなる悲しみに立ち向かう方法を考えている。



とっかかりをみつけるため、アブダクションという推論方法について触れる。 アブダクションはアメリカの哲学者・論理学者であるチャールズ・パースが19世紀~20世紀に提唱したものだが、2024年の新書大賞にもなっていた『言語の本質』*2 の中でも言語獲得における鍵として扱っており、様々な分野でいまなお注目度や重要度が上がっている概念だといえる。

アブダクション推論の形式は次の通り。

驚くべき事実Cがある
しかしHならば、Cである
よって、Hである。

ニュートンが林檎が落ちたのを見て万有引力を見つけたというのは、逸話ではなく事実だったそうで、その出来事もアブダクション推論による発見だったと言われる。 まずニュートンは林檎が落ちる（驚くべき事実C）のをみて「林檎は何故いつも垂直に落ちるのか、何故わきの方ではなくていつも地球の中心に向かって落ちるのか」という「驚き」を感じた。それに対して、「物体の中には引力が働いていて、それが地球に集中しているのでなければならない」という仮説（説明仮説H）がある。

ここで大事なのは、事実と説明仮説との間に距離、飛躍があるということだ。この飛躍が創造性をうみ、演繹法・帰納法と異なっている点である。*3

アブダクションについては、松岡正剛の千夜千冊にて『アブダクション』（米盛裕二著）をベースにして丁寧に取り上げられているのでそれを読むのが良いと思う。 その中で、次のような文章がある。

ＭＥＣＥ（ミッシー）などという合言葉が流行しています。「互いに、重複せず、全体に、漏れがない」（Mutually, Exclusive, Collectively, Exhaustive）のイニシャルをとった合言葉です。でも、これはひどくつまらない。いや、まちがっています。 パースや編集工学はそんなふうにしない。むしろ重なりから生じうるもの、漏れ（欠番）が表示すること、ズレこそがつくる意味をこそ重視するのです。なぜなら、重なりには重なるだけの、漏れるには漏れるなりのコンテクスチュアルな事情が隠れていたわけで、それらのズレから再発見もおこるからです。そこをロジカル・シンキングは消そうとしてしまう。それではダメです。*4

言葉を探す時、私もこの、「ひどくつまらない」こと ーー 重複を恐れ、漏れを埋めようとすること ーー を無意識にしてしまっているのかもしれない。

私は、この一文をベースに、思考や関心を真っ白いキャンバスに筆で色を塗りたくっていくようなイメージを持っている。 様々な色を、多様な厚みで自由に塗っていく。色がかすれているところもあれば、ムラができるところもある。色が重なることで意図していない色になったりもする。その上で、なんでそのかすれが出たのか、ムラができたのか、その色になったのかを考えてみる。そして、それが飛躍に繋がる。



言葉を見つけようとする時に、綺麗に何かを伝えようとすればするほど、積み上げるように言葉を探す。伝えようとするからこそ、綺麗な言葉・正確な言葉を探すので、元々思っていたものより小さくなったりする。そう考えることができるのではないか。

改めて最初の文章に戻ると、これはある意味「飛躍による言語化」の文章と捉えることができる。

言語化に対してこういった悩みを抱えていた自分には、あまりにも軽やかなその文章が眩しく、憧れとともに私の記憶に残ったのだろう。

私がこの文章でしていることも、まとまっている文章を書くことではなく自分の記憶に残っているものを吐き出し、繋ぎ合わせているだけだ。この文章に伝えたいメッセージがあるわけでもない。ただ、もしかしたら、そういったパッチワークのような文章を残すことで、自分の中で重なっているもの、漏れているものが見つかり、正しい言葉を捕まえることができるかもしれない。

それが正しい言葉を捕まえることに繋がるのかは、まだわからない。

*1:『海辺のカフカ』（村上春樹）https://www.shinchosha.co.jp/wadainohon/100154/

*2:『言語の本質 ことばはどう生まれ、進化したか』（今井むつみ、秋田喜美著）https://www.chuko.co.jp/shinsho/2023/05/102756.html

*3:『アブダクション 仮説と発見の論理』（米盛裕二）https://www.keisoshobo.co.jp/book/b651771.html

気づいたら2024年に新装版が出ていた

*4:「1566夜　『アブダクション』 米盛裕二 − 松岡正剛の千夜千冊」https://1000ya.isis.ne.jp/1566.html

忘れるために書く

雑記

仕事をしている中でも、本を読んでいる中でも、新しいことを知るより早いスピードでわからないことが現れる。 そうすると「あれもこれも勉強しよう」と、好奇心半分不安感半分でたくさんのものに手をだすことになる。

私は Web エンジニアとして働いているのだが、開発を進めていく中でもフロントエンド・バックエンドなど様々な領域でわからないことが増えるため、理解を深めるために記事や本を読んだりハンズオンを試すことに追われる。これは人文系の読書でも同じで、哲学・社会学など、様々な領域でわからないことができるので新しい本を手に取る。

残念ながら、そういった状態で私はよくパンクし、本は買っても机の上に積まれる。知識を一時的に保存しておくバッファプールみたいなものにも限りがあるし、並列で処理できるスレッド数にも限りがあるため、新しいものを始め過ぎた結果むしろ集中できない状態になり何も身に付かなかったという感覚が残る。

じゃあやることを制限すればいい、という話にもなりそうだが、それも少し違うと思う。制限することが先行しすぎると、技術的な進歩や重要な発見に目を瞑って自分が最初に抱いていた仮説をアップデートしないままひたすら突き進むことになるからだ。


そんなことをもやもやと考える中で、次のような言葉をみた。

書いた理由の一つは文章に残しておくことで、このテーマに一区切りをつけて次に進めるからだ。頭の中にあることを文章として身体の外に出すことで、新しいことを考えられるようになる。きっと心にも「容量」みたいなものがあるのだろう。


「成功は運か努力か才能か？についての考察」佐藤航陽 *1

まさにこれだと思った。私は始め方が下手なのではなく、区切りの付け方が下手なのだ、と。

自由エネルギー原理における「洞察」

似た話で、イギリスの神経学者カール・フリストンが提唱した自由エネルギー原理という理論がある。自由エネルギー原理とは、すべての生物は脳の予測と実際の感覚のズレ（予測誤差）を最小化しようとする、という主張で、この原理の中で「洞察」という機能について説明している。

予測誤差を最小化する正確なモデルであればあるほど複雑なモデルになる。ただし、脳のリソースには限界があるのでより単純で正確なモデルをバランスよく見つけていくことが必要になる。そして、そのような予測モデルを生成するため、脳は何か情報を受け取る度に世界からの情報を断ち、仮説を単純化する（＝洞察する）シミュレーションを実施している。*2

これに照らすと、まさに終わらせること・区切りをつけることはこの「自分の中で単純なモデルを作り、不要な情報を捨てること」が大事になるはずだ。新しいことを覚え、理解するためには忘れることが重要なのだ。

書くことで忘れる

忘れることについて、哲学者・批評家の柄谷行人の一行を挙げる。

私は一度何かを書くと、それを続けて発展させるよりも忘れてしまう習癖があります。むしろ、書くということは書いたことを忘れるためだ、と考えているぐらいです。


『日本精神分析』柄谷行人*3

いまこうやって書いてることも、この内容を忘れるためにおこなっている。忘れること自体を忘れてしまい、次の探求に進むために。

*1:「成功は運か努力か才能か？についての考察」https://note.com/katsuakisato/n/nb3786cf1cf08

*2:『脳の大統一理論』https://www.iwanami.co.jp/book/b548871.html

*3:『日本精神分析』https://www.kodansha.co.jp/book/products/0000151413

『ソフトウェア設計の結合バランス』から学ぶ、アーキテクチャの結合について

本の感想 技術

book.impress.co.jp

Vlad Khononov 著の『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』 を読んだ。開発チーム内で過剰に疎結合を評価してしまった感覚があり、その違和感が何かを突き止めるために手に取った。

全体を通じて様々な角度から結合を掘り下げるため、結合周辺の語彙が自然と整理されていく。特筆すべきは、結合を一次元ではなく三次元で評価するアプローチで、この視点が最も勉強になったので重要だと思った箇所をまとめます。

モジュール性、複雑性、均衡度

本書では結合を評価するために、「モジュール性」「複雑性」「均衡度」といった言葉を用いている。それぞれ本書での説明をひく。

モジュール性

モジュール性に投資することで、適応性の高い柔軟なシステムを設計できる。つまり、モジュール性の主な目的は、システムの進化を可能にすることだ。(...) システムの柔軟性が低いほど、耐えられるストレスも少なくなる。耐えられるストレスが少ないほど、進化する要件の重圧に耐え切れず、壊れやすくなる。変化に対応する準備ができているモジュラーシステムは、長期的成功の見込みが大きい。(p.54)

複雑性

簡単に言ってしまうと、複雑性とは理解のしにくさだ。より形式的に言うなら、複雑性とは、人が何らかのシステムとやり取りする際に経験する認知負荷を反映したものと定義できる。認知負荷が大きいほど、システムがどのように動作するかを理解するのが難しく、それを制御し、その動作を予測することも難しくなる。(p.16)

本書で出てきた表現として「私たちの認知限界は成長しないが複雑性はスーパーリニア(優線形)スケールするため、ある時点で認知負荷の増加が認知能力を上回り、その時点でシステムは複雑になる」というものがある。 モジュール性・複雑性ともに、アーキテクチャの文脈でよく出てくる表現ではあるが、本書では特に瞬間的な問題や成功を扱っているわけではなく、「長期的な変化に耐えうるか」や「動作を予測することが難しくなる」といった時間軸の考慮を重要視している。

均衡度

本書では、モジュール性と複雑性を対置させ、それを均衡度という軸で表している。このように単一のスケールを置くことで3次元での評価をシンプルにしている。

均衡度

結合の次元を組み合わせる

コナーセンスであれ構造化設計のモジュール結合であれ、結合は常に強度と関連づけられてきた。しかし、たとえば名前のコナーセンス（最も低いレベルのコナーセンス）を目指すのは、追求する価値のある目標なのだろうか。そのような目標は現実的ではないだけでなく、第7章でも示したように、実際のシステムでは不可能な場合もある。(...) コンポーネント間の相互作用を設計する際のゴールは、結合の強度を最小化することではない。ゴールは、実装や進化、メンテナンスが容易なモジュラーシステムを設計することだ。これは、結合の３つの次元すべてを考慮することでのみ達成できる。(p.177)

ここでいう「3つの次元」とは、「結合強度」「距離」「変動性」を指している。それぞれの次元に対し、結合強度であれば「高い/低い」、距離であれば「遠い/近い」、変動性であれば「高い/低い」と評価を与えることで全体としての評価を出している。

均衡度の表

例えば、コンポーネント間の結合強度がたとえ低かったとしても、コンポーネント間の距離が近いということは関連のないコンポーネントが近くに配置されていることを示している。こういった局所的複雑性がある場所で、変動性（変更の頻度予想）が高いと変更時に近くに配置された関連のないモジュールでどれを変更しなければならないかを調べる必要が出てくる。 逆に、コンポーネント間の結合強度が高いとしても、コンポーネント間の距離が近ければそれは凝集性が高いモジュールだととらえることができる。

このように、単純に結合強度という一次元ではなく、複数の側面でとらえることで実用的な評価が可能になる。

変動性とドメイン理解

特に「変動性」という次元のおかげで、単純にアーキテクチャに対して静的な分析だけではなく、サービスの成長や市場の変化をもとに動的な分析が重要なことがわかる。ドメイン理解やサービス理解が重要なことはよく言われるが、それがアーキテクチャに対してどのような影響を与えるかは私自身そこまで理解できていなかった。本書は色々な側面からアーキテクチャを検討していることで、一つの概念や用語についても全体像を意識しながら理解する手助けをしてくれる。

また、本書を手に取る前に感じていた違和感として疎結合重視の感覚をあげていたが、それについても3次元的に評価することで「結合強度が低い（単に処理が共通化されていなければいい）」というわけではないことがよくわかった。

著者は『ドメイン駆動設計をはじめよう』という本も出版しているらしく、まさに変動性について深めることができそうな本になっている。 ぜひ読んでみたい。

www.oreilly.co.jp

『体験しながら学ぶ ネットワーク技術入門』の検証環境を M4 Mac で作るために OrbStack を使用した

技術

ネットワークの勉強のため みやたひろしさん著の 体験しながら学ぶ ネットワーク技術入門 を読み始めた。 ただ、M4 Mac で検証環境を作る際に本書で提示されている Multipass をうまく動作させられなかったので OrbStack を使用して検証環境を構築しました。

動作環境

自分の動作環境は次の通り。

  • Mac mini
  • Apple M4
  • Sequoia 15.3.1
  • multipass 1.16.2+mac

Apple M4 で Multipass が動かない

本の環境構築手順では Multipass で Ubuntu VM を立ち上げることが前提になっている。

$ multipass launch 20.04 --cpus 2 --name UBUNTU --mount /Users/user01/tinet:/mnt/c/tinet

しかし Apple M4 では以下のエラーが発生して起動できなかった。

launch failed: The following errors occurred:
Unexpected error in object_property_find_err() at ../../../qom/object.c:1330:
qemu-system-aarch64: Property 'host-arm-cpu.sme' not found

＊なお、Ubuntu 22.04・24.04 も試したが、同様のエラーが発生した。

現時点ではダウングレードが回避策？

multipass に立っていた issue を見ると、1.15.x 系の途中から修正され 1.16.2 系で問題が再発したとのこと。そのため、ダウングレードすると m4 mac でも使用できるようになりそう。 今回はそもそも勉強目的で読んでいるので、multipass を使用しない方法を調べてみたところ OrbStack を見つけたので使用してみた。

OrbStack を使用しての解消

OrbStack とは

OrbStack とは、Mac 専用の軽量仮想化ツール。Docker コンテナと Linux VM の両方を一つで動かせる。Docker Desktop の代替ツールとしても注目を集めている(らしい)。

セットアップ手順

OrbStack のインストール

brew install orbstack

インストール後、OrbStack アプリを起動して初期設定を完了させる。

Ubuntu VM の作成

orb create ubuntu:22.04 UBUNTU

VM に入る

orb shell -m UBUNTU

マウントの確認

OrbStack は /Users 以下を VM 内に自動マウントする。追加設定不要で以下のパスにアクセスできる。

ls /Users/{自分のユーザー名}/tinet

スクリプトの実行のトラブル

本付属の setup_mac.sh を実行する際、いくつかのトラブルが発生した。

トラブル1: systemd-resolved がマスクされている

Failed to restart systemd-resolved.service: Unit systemd-resolved.service is masked.

OrbStack が DNS を独自管理するために systemd-resolved を無効化していた。以下で解除して再実行。 ＊ここはそこまで調べきれずに対応したので、後ほど問題が出るかもしれない。

# VM内での実行
sudo systemctl unmask systemd-resolved
sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolved
sudo bash setup_mac.sh

トラブル2: tinet バイナリのパスが異なる

スクリプトが Multipass 用のマウントパス /mnt/c/tinet を参照しているが、OrbStack では /Users/{自分のユーザー名}/tinet が正しいパス。手動でコピー/移動/シンボリックを貼るなどで対応する。

sudo cp /Users/{自分のユーザー名}/tinet/tinet /usr/bin/tinet
sudo chmod +x /usr/bin/tinet

動作確認

本書付属のスクリプトで動作確認も行えるようになっていたので実施。

sudo bash check_mac.sh
# All checks passed successfully. と表示されれば OK

まとめ

『体験しながら学ぶ ネットワーク技術入門』の検証環境の構築を OrbStack で実施した例を記載した。今のところ特に学習に支障は出ていない。 普段はアプリケーションエンジニアをなりわいにしているので、Docker Desktop でコンテナさえ立てれれば良いというくらいだったが、今回VMを立ち上げてみたことで関連サービスにどういった違いがあるかが学べた。

また、『体験しながら学ぶ ネットワーク技術入門』は想像以上にがっつり手を動かすし、そのためのスクリプトの配布などが手厚くとても勉強を進めやすい。仕事でも特に触れないと学習の時に用語だけ学んで具体では想像つかないということになりがちなのでこういった本はとてもありがたい。