最近さくらのレンタルサーバーでホスティングサイトが閲覧できないという声をしばしば見るし、私もよく遭遇するのでそれを解決する方法を紹介する。Microsoft EdgeとGoogle Chromeでの設定方法を紹介する。

このサーバーはさくらのレンタルサーバーで提供されていますという画面

Microsoft Edge

  1. 設定を開く
  2. Cookie とサイトのアクセス許可を開く
  3. セキュリティで保護されていないコンテンツを開く
  4. 「許可」にhttps://*を追加する

Edgeの設定画面

設定画面のURLとしてはedge://settings/content/insecureContentからいける。

2026-01-15追記

去年辺りからプライベートブラウズモードでは機能しなくなっているが、プライベートブラウズで有効化する方法は不明。

Google Chrome

  1. 設定を開く
  2. プライバシーとセキュリティを開く
  3. サイトの設定を開く
  4. 安全でないコンテンツを開く
  5. 「安全でないコンテンツの表示を許可するサイト」にhttps://*を追加する

Chromeの設定画面

設定画面のURLとしてはchrome://settings/content/insecureContentからいける。

フレッツ光クロスが発表されたときは毎月のように神戸市の対応状況を調べていた気がするが、いつの間にか調べなくなり、しばらく過ぎた今頃、神戸市にもクロスが来ているのに気が付いた私は10Gbps対応を考えるようになった。その中でいろいろな知見を得たので、その覚書を残しておく。

浮かれて急ぎすぎてカジュアルに初期対応をしくじって数万擦ってしまったので、同じ轍を踏まないように慎重に検討したい。

調べてみたところ2023年9月25日から神戸市は対応エリアになったらしい。

10Gbps対応について

まず10Gbpsと呼ぶケースはそこまでなく、検索ワードとしては10GbEと呼ばれているケースが多い。10Gigabit Ethernetの略。

で、この10GbE対応だが、今まであったISDN→ADSL→FTTHの流れとは毛色が違う。まず規格が乱立しているので整理する。

10GbEを利用する際に登場する用語

  • CAT6A
    • カテゴリ6AのLANケーブル。10Gbps
    • 消費電力が高く、発熱も高い
    • 国内で流通している10Gbps規格の大半がこれ
    • コネクタはRJ45、メタル線
    • コネクタが短い
  • SFP+
    • コネクタの規格。10Gbps
    • 消費電力が低く、発熱も低い
    • 10Gbps規格として国際的にはこちらが主流
    • ベンダーロックインが存在し純正ケーブルしか使えないケースがある
      • 例えばCiscoの製品を使う場合にケーブルからスイッチ、ルーター、NICに至るまですべてCisco製品で統一す必要があるなどのケースが存在する。このロックは解除する方法もあるらしい
        • 解除しても統一規格がないため正しく動かない可能性がある(相性問題)
    • コネクタが非常に長い
    • 光トランシーバーと呼ばれているもので、光信号を電気信号に変換する役目を担う
  • SFP
    • SFP+の1Gbps版

SFP+で使われるケーブルの種類

配線が7m未満に収まる場合はパッシブDACでよさそう

  • DACケーブル
    • SFP+コネクタを採用したメタルケーブル
    • ダイレクトアタッチケーブルと呼ばれることもある
    • パッシブとアクティブがあり、パッシブのほうがいいらしい
  • AOMケーブル
    • SFP+コネクタを採用した光ファイバケーブル

光ファイバケーブルとコネクタ

  • 10GBASE-SR
    • 短距離向けケーブル。最大300m。SRはShort Reachの略
  • 10GBASE-LR
    • 長距離向けケーブル。最大10km。SRはLong Reachの略
  • SCコネクタ
    • 光コンセントやONUのコネクタ
  • LCコネクタ
    • 光ケーブルのコネクタ

ルーター

OCNバーチャルコネクトが利用でき、NEC以外のもので選定。基本的に一般向けだとLAN向けの10GbEの口は一個しかない模様。

  • IODATA WN-DAX6000XR
    • OCNバーチャルコネクトには対応しているが、動作確認ISP一覧にOCNがないので除外
    • IODATAというのもイマイチ信用しづらい
    • 対応コネクタはRJ-45のみ
  • Buffalo AirStation WXR-6000AX12P
    • 安定のバッファロー
    • 実勢価格は3万ほど
    • 対応コネクタはRJ-45のみ
    • 300×195×75mmもあり、クソデカい
    • CAT6A + WiFiで運用するなら無難な選択肢だろう
  • YAMAHA RTX1300
  • GW-R86S-U1
    • 5.6万くらい。Amazonに転がってる怪しい中華ミニPC
    • Intel Celeron N5105 4C4T 2.90GHz、MEM 8GB、ストレージ128GB EMMC、NVMeスロット*1
    • SFP+ポート*2、2.5GbE LANポート*3
    • OpenWrtを入れてルーターマシンとして使う
    • RTX1300より安価なので考慮の余地あり
    • ONUから10GbEのLANを繋ぐ口がない。変換アダプタは熱がひどいと聞くのでどうか…
    • ファンの音は比較的静からしいがノートPCの平常時程度らしいのでそれなりにありそう
  • GW-R86S-G3
    • 11万くらい
    • Intel Pentium Silver N6005 4C4T 3.30GHz、MEM 16GB、ストレージ128GB EMMC、NVMeスロット*1、WiFi、Bluetooth
    • SFP+ポート*2、2.5GbE LANポート*3
    • OpenWrtを入れてルーターマシンとして使う
    • WiFi生えてるだけでこれは高すぎるので考慮しなくてよさそう
    • ONUから10GbEのLANを繋ぐ口がない。変換アダプタは熱がひどいと聞くのでどうか…
    • ファンの音は比較的静からしいがノートPCの平常時程度らしいのでそれなりにありそう
  • 今あるサーバーマシンをルーターにする
    • メリット:NIC代だけで済む。200mmファンを載せており、発熱や騒音を意識しなくていい
    • デメリット:OpenWrtを入れる必要があり微妙。サーバーとして使いたいのでルーターとは分けておきたい

NIC

CAT6A

カニのはなさそう

  • Buffalo LGY-PCIE-MG2
    • Intel(R)Ethernet Connection I219-Vを搭載したPCIeカード
    • 大型のヒートシンクを載せているが発熱が強く不安定という声をちまちま見るのが気になる
    • 低価格帯では一番有望そう
  • IODATA ET10G-PCIEB
    • レビューが少なすぎて判断できない
    • ヒートシンクの形状的が独特だが、どちらかというとこちらのほうがメジャーに見えるので冷えるのかもしれない
  • LR-LINK LREC6880BT Rev2
    • 聞いたことない中華メーカー製
    • レビューが全くないが、なんとなく期待できる気がする
  • 玄人志向 GbEX-PCIE
    • 玄人志向のわりに高い
    • ヒートシンクのやる気がない
    • レビューが少ないが安定性に期待はできそう
    • Linuxでの動作報告あり
  • TP-Link TX401
    • 一万を切っており最も安いが、TpLinkというメーカーの信頼性が微妙
    • 「※10Gで通信をするととても高温になりますが故障ではなく仕様です」と言い切っているあたり、高温になっても動いてくれそうで製品の信頼性はありそう
    • Windows 10までしかサポートされていない
  • ASUS XG-C100C
    • これまでのヒートシンクの形状から察するに一番冷えそう
    • 2万円を超えており高い
    • Windows 10までしかサポートされていない
  • Intel X540-T1
    • 偽物が流通しているらしく正規品を掴むのが難しそう
    • 2口版もある
  • 10Gtek 10Gb PCI-E NIC ネットワークカード, Intel X540-T1互換
    • やや高価
    • 中華感満載なNIC
    • Windows11がサポートされているかの状況が不明瞭、多分これまでの製品で11が外されてるのと同じ理由を抱えていそう
    • ヒートシンクの形状はべたな形で、このサイズ規模で通用するのかやや心配だが、風が通れば冷えそう
    • Linuxがサポートされており、Ubuntu 22.04での動作報告もある
    • 2口版もある

SFP+

感想

正直10Gbpsをフルで使いたいというユースケースは個人用途ではあまり多くないはずなので、根本は10GbEでそっから先は1~2.5GbE程度を各端末に分配とかでもいいような気はしてきた。現状の10GbE環境は発熱によるファンの騒音やリンクダウンなど、懸念事項が多いほか、単純に機器が高いので導入が難しい。

とはいえ、RTX830を捨ててWXR-6000AX12Pにしたらやはり役不足を感じているので、ルーターの買い替えは予定している。買い替え先としてはRTX1300かOpenWrtを載せたGW-R86S-G1辺りで検討している。しかしGW-R86S-G1にはCAT6Aが刺さる穴がないのがネックだ。変換アダプタは高熱になってリンクダウンする懸念がある。SCコネクタをSFP+に変換できれば可能性がありそうだ。

どうやらONUの中にSFP+がいるらしく、これを引っこ抜けば可能性があるっぽい?

やりたい事としてはルーターにDNSを載せたいのと、IPoEとPPPoEの共存なので、これができれば何でも構わない。調べたところOpenWrtでもやろうと思えばできそうだった。OpenWrtをGW-R86S-G1で使う場合場所を食わないことや、恐らく自由度が高いメリットがある。半面保守の手間はかかるだろうし、寿命がどれほどあるのかは怪しいのと、安定性である。RTX1300は腐っても製品なので、そういったデメリットはカバーしてくれる。サポートも手厚く、問い合わせれば答えてくれる。

正直10Gbpsをフルに使いたいというより、帯域を増やしてサーバーを出したいのと、通常使用でも偶に100Mbps付近まで落ちることがあるので、上限速度を上げて相対的に速度の下限を上げたいみたいなところが大きい。

検討結果まとめ

今までに調べてきたことを総合的に勘案したまとめ。ONUからルーターは10Gbps、ルーターから各機器は1~2.5Gbpsの想定。

  • ルーター
    • 安定性を求めるならルーターはRTX1300、価格を求めるならGW-R86S-G1
  • ONUとルーターの接続
    • RTX1300ならCAT6A、GW-R86S-G1ならONUからSFP+抜いて刺す
  • ルーターからNICへの接続
    • 必要に応じてCAT6Aに上げる
  • NIC
    • 現状維持
    • サーバー機は必要に応じてNIC足してもいいかもくらい(1000BASE-Tが上限なので)

まとめから導き出した結論

どれもコストが掛かるのとファンの音が出るのは嫌なので10GbEはWANだけにしてLAN内は現状運用とする。凝った環境はもうちょい10GbEが普及してきて価格や発熱とかが色々マシになってきたらかなぁ…とは思うものの、一般消費者にそんな普及するとも思えないし微妙か。

クロス自体を取りやめにするのもなくはない気がしてきた。

参考情報

更新日:
投稿日:

紙の書籍の魅力といえばデバイスがいらないことや、パラパラ読めること、紙の質感があることなどがあると思う。しかしまだそれより先があるのではないかと思い、私はある一つの点を思いついた。現実世界の書店、とりわけオタク向け書店の存在だ。

とらのあな、メロンブックス、アニメイト、ゲーマーズをはじめとしていくつか存在するが、昨今では男性向けの書店が閉店する傾向がある。書籍は電子化により物理書店が減っているというのはオタク向けに限らず有名な話だが、実はオタク向けに限って言うと女性向けが比較的健在という話がある。例えば「とらのあな「ほぼ全店閉店」衝撃発表の理由とは? 店舗事業撤退の裏側を聞いてみた」という記事では、とらのあなが池袋の女性向け店舗だけ残したという話が出ている。

そこで私は一つの仮説を閃いた。男性向けと女性向けでは何か決定的な違いがあるのではないかということだ。女性は機械が苦手だから、みたいなのもゼロではないと思うが、どっちかといえば携帯小説など女性向けでも電子媒体は強い力を持つと思うし、創作分野においては女性のほうがデジタルに分を持つだろう。それでも紙媒体に何かがあるというのならそれは何だろうか?というのが気になったので私は早速スーパーに出向いた。

何故ならスーパーには女性向けの書籍が多いからだ。そもそも生鮮食品や生活雑貨が主たる商材であるスーパーに本がある。これは面白いことである。取り扱う必要性がないはずのものがあるということは売れているわけだ。

今回購入した「りぼん」

取り敢えず私は目を引いた雑誌を一冊手に取った。むしろこれだけアピールされていて買うなというほうがおかしい。今までは何となく気が引けて手に取ったことはなかったが、今回ついに手に取ってしまった。正直それが目的だったのでは?と言われたら、それも否定はできない。正直女性向け漫画にも興味自体はあった。というわけで集英社のりぼんを買った。恐らく小中学生向けの雑誌だと思う。男性向けでいえばコロコロコミックやコミックボンボン辺りが近い存在だろう。なおコミックボンボンはもうないらしい。通りで最近見ないわけだ。

さて早速だがまず表紙を見てみると付録がついていることが解る。推ししか勝たんうちわセットだ。電子書籍では物理的なおまけはつけようがなく、あっても精々期間限定アクセスのデジタルコンテンツ程度だろう。

付録の推ししか勝たんうちわセット

デジタルおまけはサービスの会員登録に誘導されて迷惑な販促メールがくる懸念があるうえ、内容も微妙なので魅力が低いと思っている。しかし物理は違う。開けてみるとかなり本格的なセットになっていることがうかがえた。普通に出来がいいし、ちゃんと使えそうなレベルだ。アニメイトに売ってそうだし、買うと地味に高そうなやつ。しかし付録なのでタダに等しい。

紙の下地がカラフルなことが解る断面
最後のページはカレンダーとして使えるようになっている

他にも折り込みページがあって見開けたり、作品ごとに紙の下地の色が違ったり、最後のページがイラストカレンダーになっていたり、クロスワードパズルのようなものがあり、懸賞応募ができるなど、何かと作りがよく、普通に尊い作りになっていて感動した。表紙だけでも十分に尊いのに一体どれほど尊さを追求してくれるのかという感じだ。尊み秀吉である。男性向けのこのクラスの雑誌がどうだったかが記憶にもうないので、今度そちらも見てみようとは思うが、ここまでではなかった気がする。

まぁここまで気分が高揚してしまっているのは、単に初めて見るものだからというのもあるとは思うし、付録も今回たまたまついていただけという可能性はあるし、そもそもこれは児童誌であって大人が読むものではないので、まともに扱うこと自体に無理があるが、紙本の魅力の一つとして数えること自体はできる気はする。特に前述したクロスワードパズルのようなものは紙に書いてこそだと思うので、これはいいものだろう。デジタルのマス目にキーボードで埋めるのは味わいがない。

しかしこの本を買って思ったのは表紙がパステル調で、ポップで非常にファンシーで、これはすごく心をくすぐられる要素が強いなというところだ。電子だとあんまこれは感動しないかもしれない。たぶん画面のフレームの一部であって、視界全体に移りこまないからかもしれない。

ちなみに単行本などは場所の都合で電子で買っているのだが、雑誌は紙で買うようにしている。紙のほうが読みやすいのと、部屋に転がしておくと目に留まって何度も読むからだ。電子はアプリを開かない限り見えないので文化から隔絶された感覚になる。PCだと寝転がって見れないし、スマホは小さい、タブレットは悪くないがそのために持ちたくないというのが正直なところだ。

りぼんの発行情報
モーニングの発行情報

また紙の本を見ていると発見があることもある。例えば今回気が付いたのは発行情報だ。りぼんには『(毎月3日発売)第70巻第6号』と書かれている。これはほかの雑誌ではどうだろう?と思い、モーニングを見てみたところ、『(毎週1回木曜日発行)(4月25日発売)第43巻第22号通巻2383号』と書かれていた。

恐らく巻数は発行年数で、号数は発行月数だと思うので、りぼんの場合は70年目の6月号であることが解る。モーニングは週刊誌なので22週目ということだろう。通号の有無に関してだが、これはモーニングがもともと第三種郵便物であった名残であると思われる。第三種郵便物には逐号番号の記載規定があるので、その名残。りぼんは第三種郵便物だった事がないか、名残がないかのどちらかだろう。

またモーニングにある「毎週1回木曜日発行」という、毎週一回と木曜日発行がダブっていて違和感を覚えるのも、これも第三種郵便物の書式規定によるものと思われる。恐らく週の発行回数を明示するために意図的に書くように定めたものなのだろう。

さてここまで内容について一切触れていないが、内容についても面白く、傾向としてはコミカルな表現が多く、恋愛ものが多い。ファンタジーやバトル、ギャグ物は少ない印象を受けた。

2002年のJMPA読者構成データ

読者層としては2002年のJMPA読者構成データを見る限り、13歳未満が64.6%で過半数を占め、次いで13~15歳が31.2%、16歳以上が4.2%、性別では女性が100%となっている。

対象年齢的には中学生以下が一般的で、中学生も多少読んでいる感じだろう。こういう場合、親が買い与えていると思われるので男性の読者比率が0%になっているのだと思う。とはいえ、内容的にはそこまで低年齢向けかというとそこまででもなく、振り仮名こそ振ってあるものの、その中身は意外と本格的だった。小学生がこの言葉やシチュエーションわかるんか?というのがそれなりに出てくる気がしたので、そこそこませている。登場人物は高校~社会人くらいなので、割と高めである。少年誌の登場人物が軒並み高校で時が止まっているのと比べると、これは対照的だ。男性向けだと、社会人が出てくるのは青年誌以降だろう。

絵柄は少女漫画的なのはそこまで多くなく、所謂萌え絵みたいなのが多めである。少女漫画チックなのはかなり少なく、どちらかというと萌え絵に寄ってきている。ディズニーとかも昔と比べるとそっちに寄ってきている気がする(アナ雪とか)ので、これは界隈の傾向なのかもしれない。基本的には男性でも普通に読める内容だが、女の子の夢みたいなのがふんだんに詰まり気味であるため、分別のつかない男児に読ませるのは妙な誤解を生んだりする可能性があり、微妙かもしれない。

作品的にはちびまる子ちゃんが連載されており、作者がすでにこの世を去った状態なのに連載が続いているのは凄いと思った。

関連記事

投稿日:

process.exit()のラッパーだったり、throwする関数だったりして、戻り値がneverを取る関数で、TypeScript上、後続処理がデッドロジックになるものを作る方法。

確認環境

Env Ver
TypeScript 5.4.5

やりたいこと

process.exit()を書くと次の行以降がデッドロジック扱いされる

process.exit()を書くと次の行以降がデッドロジック扱いされるが、これをやりたい。

問題点

普通に実装して型推論に任せてもうまくいかない。

関数の戻り値型はnever
neverなのに後続がデッドロジック扱いされない

例えば次の左図の関数の戻り値型はneverだが、右図ではデッドロジックとならない。

戻り値の型にneverを直書きしても機能しない

このように戻り値の型にneverを直書きしても機能しない。

解決策

関数そのものの型を作る
関数そのものの型があれば、後続もデッドロジック扱いされる

左図のように関数そのものの型を作ると解決できる。右図を見るとデッドロジックになっていることが確認できる。

何のためにこれをやるか

デッドロジック扱いされない状態では戻り値の状態が不正になる

別の関数から呼んだときに、呼び側の関数の戻り値型を正しくするためだ。下図はデッドロジックになっていない状態のときのものだが、処理が死なずに通り抜けてしまうのでundefinedが帰ることになっており、この関数の呼び下でundefinedだった時の処理を書く必要が出てきてしまう。

しかし、デッドロジック扱いになっていれば下図のように戻り値の型が期待した通りの内容になる。この関数がundefinedを返すことはないので、この状態を実現するために行っている。

関連記事

投稿日:

依存ライブラリの関係でESLint v9への移行はできていないが、取り合えずFlat configに移行した。ESLintは7.9.0から8.57.0に更新している。

確認環境

Flat configになってからeslint:recommendedは@eslint/jsに移った模様。

Env Ver
@eslint/js 9.2.0
@lycolia/eslint-config 0.9.1
@swc/jest 0.2.31
@types/jest 29.5.11
@types/node 20.11.5
eslint 8.57.0
eslint-plugin-jest 28.5.0
jest 29.7.0
prettier 3.2.5
typescript 5.4.5
typescript-eslint 7.8.0

元の設定

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:jest/style",
    "plugin:jest/recommended",
    "@lycolia/eslint-config",
    "prettier"
  ],
  "plugins": [
    "@typescript-eslint"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json"
  }
}

やったこと

ESLintなど必要ライブラリのアップデート

npm i -D eslint @eslint/js eslint-plugin-jest jest prettier typescript typescript-eslint @lycolia/eslint-config

新設定の作成

eslint.config.jsを作成

extendsの設定

今までextendsに書いていたものはrequireでモジュールを参照してmodule.exports = []の配列の中に書いた。typescript-eslintとeslint-plugin-jestの対応が何とも言えない。なお、この状態だとtypescript-eslintが正常に動かない。

const eslint = require("@eslint/js");
const eslintTypeScript = require("typescript-eslint");
const eslintJest = require("eslint-plugin-jest");
const eslintLycolia = require("@lycolia/eslint-config");

module.exports = [
  eslint.configs.recommended,
  eslintTypeScript.configs.recommended[0],
  eslintJest.configs["flat/style"],
  eslintJest.configs["flat/recommended"],
  eslintLycolia,
];

設定が競合して都合が悪かったので、この時にPrettierの設定を削除しているが、Flat config化とは特に関係ないので無視してよい。

@lycolia/eslint-configは私が作っているカスタム設定だが、これは特に何もせずとも使えた。

.eslintignore対応

extendsしたオブジェクトの次にオブジェクトを記述し、そこにignores: []を追加し、その中に同じことを書いた。恐らく根っこの配列はESLintの設定オブジェクトの羅列で、最終的に後勝ちでマージされる様に出来ているのだろう。

const eslint = require("@eslint/js");
const eslintTypeScript = require("typescript-eslint");
const eslintJest = require("eslint-plugin-jest");
const eslintLycolia = require("@lycolia/eslint-config");

module.exports = [
  eslint.configs.recommended,
  eslintTypeScript.configs.recommended[0],
  eslintJest.configs["flat/style"],
  eslintJest.configs["flat/recommended"],
  eslintLycolia,
  {
    ignores: [
      'dist/*',
      'coverage/*',
      '**/*.d.ts',
      '/src/public/',
      '/src/type',
      '*.config.js'
    ],
  }
];

TypeScript対応

eslintTypeScript.config()でESLintの設定配列全体を引数としてラップし、languageOptionsの中身を移植した。旧設定にあったplugins公式のドキュメントを見る限り不要になっている模様

const eslint = require('@eslint/js');
const eslintTypeScript = require('typescript-eslint');
const eslintJest = require('eslint-plugin-jest');
const eslintLycolia = require('@lycolia/eslint-config');

module.exports = eslintTypeScript.config(
  eslint.configs.recommended,
  ...eslintTypeScript.configs.recommended,
  eslintJest.configs['flat/style'],
  eslintJest.configs['flat/recommended'],
  eslintLycolia,
  {
    ignores: [
      'dist/*',
      'coverage/*',
      '**/*.d.ts',
      '/src/public/',
      '/src/type',
      '*.config.js'
    ],
    languageOptions: {
      parser: eslintTypeScript.parser,
      parserOptions: {
        project: './tsconfig.json'
      }
    }
  }
);

旧設定の削除

.eslintrc.eslintignoreを消した。

ESLint v9対応

typescript-eslintが対応していないため、現時点ではできなかった。

変更差分まとめ

-{
-  "extends": [
-    "eslint:recommended",
-    "plugin:@typescript-eslint/recommended",
-    "plugin:jest/style",
-    "plugin:jest/recommended",
-    "@lycolia/eslint-config",
-    "prettier"
-  ],
-  "plugins": [
-    "@typescript-eslint"
-  ],
-  "parser": "@typescript-eslint/parser",
-  "parserOptions": {
-    "project": "./tsconfig.json"
+const eslint = require('@eslint/js');
+const eslintTypeScript = require('typescript-eslint');
+const eslintJest = require('eslint-plugin-jest');
+const eslintLycolia = require('@lycolia/eslint-config');
+
+module.exports = eslintTypeScript.config(
+  eslint.configs.recommended,
+  ...eslintTypeScript.configs.recommended,
+  eslintJest.configs['flat/style'],
+  eslintJest.configs['flat/recommended'],
+  eslintLycolia,
+  {
+    ignores: [
+      'dist/*',
+      'coverage/*',
+      '**/*.d.ts',
+      '/src/public/',
+      '/src/type',
+      '*.config.js'
+    ],
+    rules: {
+      semi: ['error', 'always']
+    },
+    languageOptions: {
+      parser: eslintTypeScript.parser,
+      parserOptions: {
+        project: './tsconfig.json'
+      }
+    }
   }
-}
+);