お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。

日本国という主権国家について

投稿日：
ジャンル::随想

昨今キャッシュレスや電子決済という言葉が流行っており、政府レベルで推進が続いている状況だ。しかし、そこで気になるのは現金の扱いがどうなるのかということだ。

さてこの度、新紙幣発行が近づいてきて、対応問題が以下のようにニュースになっている。

キャッシュレス対応をすれば確かに新紙幣に対応するコストは減らせるだろう。しかし、もしすべてをキャッシュレスにした場合、通貨の信用がどのように担保されるのかというのは一つ問題になると思う。決済系の事業者は民間企業であるから、基本的に通貨の信頼性を担保する役目はない。勿論、担保してもいいのだが、事業者が複数ある以上どのようにして担保されるのかや、事業者間での通貨交換をどのように実現するのかという課題は出てくるだろう。

そしてまた、問題はそれだけではないと個人的には考えている。それは決済事業者による取り扱いの取りやめである。

例えばpixiv, DLsite, Fantiaの各社がクレジットカードの取り扱い停止に対する声明を発している。最近気になっていることでも触れているが、この流れが加速するとアダルトコンテンツを取り扱っている事業者はクレジットカード決済が利用できなくなる可能性がある。またクラウドプラットフォームに拡大した場合にAWSなどがアダルトコンテンツ事業者へのホスティング停止や、アダルトコンテンツ事業者で利用できる決済システムの廃止をしてくるかもしれない。例えばPayPayはAWSで動いているとされるが、PayPayを利用してアダルトコンテンツを購入することは可能だろう。その観点で考えた場合、PayPayもプラットフォームから追放される可能性がある。

個人的にその動きが拡大した場合に憂慮しているのが、VISA, Master, AMEX, Dinersなどが日本から撤退し、JCBは人権侵害国家のシステムとして国際的に排除される可能性だ。そうなってくると究極的には日本国そのものが経済制裁の対象になる可能性もあるだろう。アダルトコンテンツの取り扱い事業者が多く、それを政府が容認しているし、何なら非欧米的なシステムや人権の取り扱いが多いということで、中露同様に非国際的な国家として弾圧を受け、経済制裁などの対象になる可能性もあるだろう。

ただしこれを回避する手段もある。日本が欧米同様の法システムと人権システムを導入することだ。日本外務省は人権問題に関する指摘は内政干渉にならないと発表しているため、要するにこれは可能である可能性が高い。しかしその場合、日本の主権というものはどうなるのかという部分が気になる。人権問題というのはどうにでもこじつけることができるし、アダルトコンテンツを扱っているというのは昨今の国際情勢からみると非常に危うい。ただ、世界中の国家を均一的な法体制にするということは国家の多様性を失わないか？最終的にローマ帝国の再来ではないかと考えたりもする。

果たしてそれでいいのだろうか？私は日本には諸外国にはない高い表現の自由や、文字通り様々な自由があると信じているが、昨今の圧力や、欧米文化の流入により、徐々に失われていくような感じを受けている。

本来通貨というのはアダルトコンテンツだろうが何だろうが使えていいものである。それが反社会勢力の締め付けなどで制限をかけるようになり、反社会的活動をしているとされるアダルトコンテンツ事業者にも波及するようになった。このままいくと日本国そのものが反国際社会的国家の烙印を受け、国際社会から追放されることがないのかというのが懸念である。

結論として言いたいことは、キャッシュレスを推進することによって日本の主権が諸外国から侵害されやすくならないかということと、日本国自体がアダルトコンテンツ規制方面に舵切りを行うようにならないかという懸念、そして日本という主権国家の個性が徐々に失われていき、最後には無にならないかということだ。

コメント（0件）

REST APIとGraphQLについて比較してみる

投稿日：
開発::設計開発::Web

この記事では下図のシステム構成を前提に話を進めるものとする。この時、BFFの部分のアーキテクチャをREST APIにするか、GraphQLにするかというのが今回の話。

http-archtecture.png

REST API

長所

  • Web標準であるため特別な技術が必要ない
    • ファイルアップロードのような特殊な通信プロセスも何も考えずに実装できる
    • エラーもエラーコードを返せばいい
  • 学習コストが低い
  • 設計が単純
    • エンドポイントに何かを要求すれば、それに対する応答が帰ってくるという点で非常にシンプル
    • CRUDはGET/POST/PUT/DELETEで分かれており、これも単純
  • 依存するライブラリがない
    • 破壊的変更を受ける可能性がない
    • renovateによるアップデート地獄とも無縁
  • BFFとフロントエンドで型情報の共有が容易
    • BFFをTypeScriptで実装していれば、そのまま型情報が流用できるし、他の言語で実装していてもOpenAPIを作り、そこから型情報を得ることが可能だ
  • curlからリクエストを投げやすい
    • 基本的にペイロードが単純であるため

短所

  • 複数のデータを取得する際に複数回APIを呼ぶ必要があり、オーバヘッドが大きい
    • 今回のケースでは呼び出し先のAPIはBFFによって集約されているため、適切にエンドポイントを設計すればこの問題は回避できる
  • オーバーフェッチとアンダーフェッチ
    • データを取得しすぎたり、取得しきれないといった問題が発生することがある
    • 例えば/api/v1/userからユーザー名だけを取得したい場合に、ユーザーIDや年齢といった余計なデータが付随してしまうことがあったり、このエンドポイントからそのユーザーのログイン履歴を取得することができなければそれはアンダーフェッチになる
    • 今回のケースでは呼び出し先のAPIはBFFによって集約されているため、適切にエンドポイントを設計すればこの問題は回避できる
  • エンドポイントが増えすぎると何が何かわからなくなる
    • GraphQLでもQueryが増えすぎれば同様の問題だと思うのでREST API固有の問題だとは思わない
  • レガシーな技術
    • レガシーというのはそれだけで悪である

GraphQL

長所

  • モダンであり、流行っている
    • モダンであり、流行っているということはREST APIより良い選択肢であると言える可能性がある
  • クエリを利用した柔軟な要求が可能
    • REST APIと異なり特定のエンドポイントに縛られることがない
    • またクエリを読むことで、フロントエンド側の実装のみで、どのような要求なのかを知ることができる
  • フロントエンド側で取得したいデータを制御できる
  • エコシステムが充実している
    • キャッシュやエラーハンドリングは勿論のこと、Reactなど特定のフレームワークと統合するための仕組みが存在する
  • デバッグ用のブラウザ拡張機能が存在する
    • デバッグ用のブラウザ拡張機能が存在し、これがあるとデバッグがしやすい

短所

  • Web標準ではない
    • ファイルアップロードのような特殊な通信プロセスは追加のライブラリなどが必要になるケースがある
  • 学習コストが高い
    • 非常に充実したエコシステムが存在するということは反面学ぶことも多いということになる
      • Web標準ではないが通信にはHTTPを使っているため、Web標準を知らなくていいわけではない
      • GraphQL標準のようなものは存在し、それと別にライブラリの構成についても学ぶ必要がある
    • REST APIのノリで利用するのであれば使う意味がない
  • 型システムとの相性が悪い
    • クエリを利用し柔軟にデータを要求できるということはデータ構造が不定であるため、静的型付け言語との相性が悪い
    • 多くの場合、辞書型を使って処理することになると思うが、このままでは不具合を引き起こしやすく、型の正規化を行う場合余計な処理プロセスが入ってしまう
    • また型の正規化をするための関数を個別に作っているとやっていることがREST APIと大差なくなる
  • 設計が難しい
    • スキーマ設計が難しいと言われており、HowTo記事が多くある。AWSにさえある
    • 何でもかんでも取得できる魔法のリゾルバみたいなのを作ってしまうとフロントエンド側で取得できてはならないデータまで取得できてしまうためよく考える必要がある
      • 例えばクエリに応じた内容をDBから引っこ抜いてくる実装だったりすると、他のユーザーの情報を取得するなどができてしまうので結局BFF側でもある程度の作りこみが必要になる
      • 他にもN+1問題が起きるとパフォーマンスが悪くなるどころか、最悪サーバーが落ちることすらあり得るだろう
  • 実装が難しい
    • 学習コストが高い部分と同じだが、全員がGraphQLとそのライブラリの理念を理解するのはあまり現実的ではなく、実装が難しくなる要因になると思う
  • 開発ツールの対応状況があまりよくない
    • VSCodeを開発に使おうとしたときにGraphQLの対応状況があまりよくなく、入力補完やLintなどをいい感じにしてくれる存在がいない
  • ライブラリの保守作業が必要
    • ライブラリはアップデートされ、時として破壊的変更も起きるものなので、それらの対応が必要
    • renovate地獄の一翼を担う存在になる
  • curlからリクエストを投げづらい
    • クエリ文が複雑になればなるほど投げづらくなる
    • 下手したらこれだけでオーバーフェッチとかどうでもよくなるレベルだと思う
コメント（0件）

トラペジウムを見てきた

投稿日：
作品::トラペジウム文芸::アニメ文芸::映画

トラペジウムというアニメ映画を見てきた。余りに衝撃的だったので記事にしてみようと思う。

実は映画館の予告とかで存在は知っていたのだが、キービジュアルとAKB48系ということで初めは見る気がなかった。しかし映画館でポスターを見た時、これは見ないといけないと思ったのだ。

0d0d842499d97a01.jpg

ポスターを見ると色々あるが、個人的にはこの辺りが刺さった。「楽しくなかったら許さないからね。」「来なさい、死にものぐるいで。」「ボランティア活動とか興味ないですか？」「私たちは元々友達だったんだから。」どう考えても狂気がこもったメッセージである。正気ではない。見ないと損をする。瞬時に脳裏をその感情がよぎった。

そして観てきた感想だが、これはすごくよかった。人の感情がこれでもかと詰まった作品だ。内容を端的に言うと精神的に未熟な学生が、挑戦と失敗を繰り返し苦汁をなめながら、立派な大人になる過程を描いた成長譚だ。

登場人物としては絵に描いたような箱入りお嬢様、陰キャ系の技術オタク女子、いじめられっ子根暗から整形で転生し普通人間に擬態した女子、頭がよくスペックは高いものの精根腐りまくりで強かなアイドル志望主人公といった感じで、非常に個性的だ。

主人公はアイドル仲間を集めるために東西南北の名前が付いた高校から謀略的にメンバーを集める。友達になろう、技術のことに興味があります、そんな噓を重ねてどんどん人を集める。中には、その学校の男子生徒の下心を逆手にとって勧誘するシーンさえもある。ここはこの作品のキーとなるポイントで、エンディングで最も輝く伏線として機能することになる。

そして絆づくりをしたり、将来アイドルとして有名になったときに経歴を調べられても問題がないようなアリバイ工作まで、様々な謀りを行う。高校生とは思えない行動力である。

しかし偽りの絆で互いの意思とは関係なく集められたアイドルはすぐに破綻する。それはもう全員感情を限界まで発露するのだ。「こんなことしたくない！」「このままでは私は壊れてしまう！」そういったことを次々と話にするのである。

それから間もなくし、アイドルは解散する。主人公は他の全員から責められる。そして全員解散する。これで終わりか…と思うものの、そこからまた絆を取り戻すストーリーがあり、この一件をきっかけに全員がそれぞれの夢を見つけ、大人になりそれぞれの夢を達成し、また出会う。

そしてその時、昔下心をもって近づき、結局実らず、利用されるだけだった真司が、展示会を開く。すると、そこにはかつて、まだみんな楽しく本当に笑っていたころの集合写真があったのだ。そのタイトルこそが、そうtrapeziumなのだ。真司は星を撮影することが好きなカメラマンだった。そして、この写真は星として輝くアイドルを撮影した一枚だったのだ。

所々で出てくる主人公の悪態や自己中心的な態度、傲慢さ、他の登場人物から発露される葛藤、公開、憎しみ、そういった強い感情が多く表現されており、非常に人間味のあるストーリーで個人的にかなり良かった。

しかし本作は映画の予告シーンやキービジュアルからは全く予想できないような内容だったので、恐らくギャップを楽しんでほしいという思いがあるのかもしれないが、そこまで名のある原作ではないこともあり、映画館はガラガラだった。元々はよくあるアイドル物的な内容に終始する宣伝しか打たれていなかったと思う。口コミは悪くないように見えるが、設定が複雑でセンチメンタルな感情を描いた作品ということで、端的に言うとめんどくさいオタク向け作品であり、恐らくそこまでヒットすることはないだろう。どのくらい面倒かというと岡田麿里作品よりも面倒だ。個人的には、こういうのがかなり好きなのだが、残念ながら基本的に私が好む作品はヒットしない。

二回目を見てきたので、トラペジウムを見てきた その２を書いた。

コメント（0件）

EdgeやChromeでさくらのインターネットで運営されているサイトを表示できるようにする方法

投稿日：
ソフトウェア::ブラウザ::Chromeソフトウェア::ブラウザ::Edgeジャンル::インターネット

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

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

Microsoft Edge

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

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

Edgeの設定画面

Google Chrome

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

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

Chromeの設定画面

コメント（0件）

フレッツ光クロス、10Gbps対応に関する覚書

投稿日：
ジャンル::インターネット自作PC::NICジャンル::ガジェット

フレッツ光クロスが発表されたときは毎月のように神戸市の対応状況を調べていた気がするが、いつの間にか調べなくなり、しばらく過ぎた今頃、神戸市にもクロスが来ているのに気が付いた私は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が普及してきて価格や発熱とかが色々マシになってきたらかなぁ…とは思うものの、一般消費者にそんな普及するとも思えないし微妙か。

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

参考情報

コメント（0件）