コンピュータの日記です

目次

2022-09-26 スプラ3のフェス
2022-08-19 vue-tweet-embed で表示していた Tweet が崩れる
2022-07-23 プリンタ購入
2022-06-14 CAPCOM
2022-04-05 代入の評価順
2022-04-04 停電
2022-02-27 BABA IS YOU
2022-01-27 node.jsの2つのイベント処理
2022-01-11 続・グノーシア
2021-12-22 Windows 11
2021-11-30 i-mode終了
2021-11-25 グノーシア
2021-10-10 ネットワークHUB故障
2021-10-08 コンピューターと気象予測
2021-08-29 SSL 証明書
2021-07-24 IOCCC
2021-07-18 続・FFMPEG
2021-07-17 FFMPEG
2021-07-04 251D 使用レビュー
2021-07-04 QNAP TS-251D 購入
 …同じテーマのほかの記事
スプラ3のフェス  2022-09-26 15:03:04  コンピュータ

▲目次へ ⇒この記事のURL

スプラ3の第1回フェスが終わった。


…改めて、この手のイベント運営の難しさを感じた。



スプラ2は最初の2年間しかフェスをやらなかった。

ファイナルフェスは 2019年の1月。


実際にはその後も不定期に特別なフェスが行われたのだけど、それも 2021年1月が最後。


正直に書くと、僕はもともと対戦ゲームは苦手だし、3Dのシューティングも苦手。

スプラ2は、最初の内こそ遊んでいたが、途中からは「フェスだけ参加」になっていた。


そんなわけなので、本当に久しぶりに遊んだのが、スプラ3の「発売直前」の無料お試し。

これもフェスの扱いだったのだけど、本当に特別扱いなので適当に楽しんだだけ。


今回、1年半ぶりのフェスで、詳細すっかり忘れていた。




遊んでない人には何やらわからない話なので、軽く説明しよう。

スプラ3、正式名スプラトゥーン3は nintendo switch 向けのゲームだ。


3Dで描画された画面で、敵陣営と味方陣営に分かれて撃ち合いをする「シューティングゲーム」だ。


この手のゲームは、もう10年くらい前からアメリカを中心に流行していた。

しかし、日本ではどうも流行らない。


任天堂社内に、この手のゲームを「好きなグループ」がいたそうで、彼らが日本でも流行させようとして、既存のゲームの「日本人受けしない」部分を徹底的に洗い出し、受け入れられる方法を考えた。


結果として、世界中で流行するゲームになった。

「日本人受けしない」と考えていた部分は、実は海外でも嫌いだった人が多いのだ。



最初に書いたが、僕はこの手のゲーム嫌い。でも、スプラは楽しめる。

撃ち合いのゲームであるにも関わらず、最終的な結果が「敵を倒した数」ではなく、「ナワバリの面積」で決まるためだ。


撃ち合いと言いつつ、武器も水鉄砲という設定になっている。

その水鉄砲で地面を塗る。塗ったところが「ナワバリ」になる。


人に銃を向ける、という内容に抵抗がある人も、直接対決が嫌だ、という人も楽しめる。

最終的には、前線で殺伐とした殺し合いになるけどね。




それで「フェス」だ。


普段のゲームだって十分面白いが、僕がフェスだけ参加する、と書いているように、より「特別感」のあるゲームになっている。


期日指定で、遊んでいる人がいくつかの「陣営」に分かれて、大きな勝負をする。


この陣営は、簡単なアンケートで決まる。

例えば、スプラ2の最初のフェスは「マヨネーズとケチャップ、どちらが好き?」だった。



フェスの時でも、1回1回の勝負は、いつものゲームとあまり変わらない。

でも、そのゲームの勝敗が、より大きな「勝負」を決めていく。


この「フェス」が、スプラシリーズの非常に面白いところであり…運営が非常に難しいところだ。



僕は初代のスプラは遊んでいないのだが、初代の最初のフェスはひどいものだったらしい。


2つの陣営に分かれて戦うのだが、「人数が少ない陣営」の人数が少ない。

何を当然のことを、と思われるだろうが、フェスは「2つの陣営」が戦うのだ。

両者が同じ人数でないと、勝負が成立しない。


結果、人数が多いチームでは、遊ぼうと思っても「相手がいない」状態で待たされる。

人数が少ないチームは、寝ないで遊んでくれ、という懇願がネットの掲示板に描かれる始末。



その後、人数が少なくて試合が成立しないときは、「同じ陣営」の人同士が戦う、という同士討ちが作られた。

これで「ゲームが遊べない」ということは無くなったが、同士討ちはフェスの結果には無関係なので、あまり多いと興ざめする。


例えば、先ほど書いた「マヨネーズとケチャップ」だが、このお題はあまりよくない。

日本国内では半々程度に分かれたのだが、海外では圧倒的にケチャップが多いのだ。


これ、日本国内だとよく「似たようなもの」扱いされるのだけど、海外では「ドレッシングと、なんにでも使える万能ソース」だからね。

どちらが好き、と言われたら、なんにでも使える方が好きに決まっている。


こういう時、同士討ちだらけの詰まらないフェスになってしまう。




さて、それでやっと今回の本題に入れる。


スプラ3では、フェスが「3陣営」に分かれるようになった。


これ、素直にいいアイディアだと思った。

2陣営だと、必ずどちらか一方は「過半数」を取るのだ。

相手より人数が多くなったチームには、同士討ちが発生してしまう。


3陣営に分かれれば、「自分の陣営」は、おそらく「残る二つの陣営の合計」よりは人数が少ないだろう。

常に自分は「人数の少ない側」になり、他のチームと対戦することができる。


実際、発売前のお試しでは、「グー、チョキ、パー、どれが好き?」というお題で、それほど人数差もなくうまく遊べていた。



で、今回の第1回フェスだ。


「無人島に持っていくなら?」で、道具・食料・ひまつぶし の三択だった。


これ、海外でも同じ内容なのかな? 

どうもネットで情報探しても見つからないのだけど、事前調査を「世界的に」行って決めた三択ではないかと思う。


無人島、と聞いて、日本人はテレビのバラエティー番組の「無人島生活」や、遭難して無人島に漂着、と言ったシチュエーションを思い浮かべることが多い。


でも、海外では「無人島リゾート」も結構多いのだ。ちゃんとホタルが整っていて、島を丸ごと1つ貸してくれる。

そういうところでは暇つぶしという選択肢もありだろう。


でも、フェスの開催を伝える際の、キャラクターの寸劇は、「ガチで遭難し、いつ助けが来るかもわからない」という状況のものだった。

その状況で「ひまつぶし」はあり得ないし、食料だってすぐ尽きてしまうだろうから、食糧確保のための道具、と考える人が多かったようだ。


結果、3択なのに道具が過半数を超えてしまった。


これにはもう一つの裏があり、フェスの際はそれぞれの陣営に「キャラクター」が付くので、キャラの人気投票になりやすい。

道具には一番人気のキャラが付いた。これも過半数を取る原動力になっただろう。


ともかく、せっかくの「同士討ちを出さない工夫」は役に立たず、第1回フェスから同士討ちが頻発するものとなった。



ついでに言うと、スプラ3はフェスの後半で、前半で「一番勝率が高かったチーム」4人に対し、残る2チームが2人ずつ参加して3色で陣取りをする「トリカラバトル」というものがある。


今回、一番得票率が少なかった「ひまつぶし」陣営が、前半での勝率が一番高かった。


結果として、トリカラバトルはほとんど成立しない。特に、道具陣営の人にとってはせっかくの最初のフェスでトリカラバトルが全然遊べない、ということになったようだ。



#ちなみに、僕は食料派だった。

 ガチ遭難の場合、最初の1週間を生き抜くのが難しい。

 見知らぬ島での食糧確保をどうすればできるのか、という調査だけで時間が過ぎてしまうためだ。

 道具はこの調査が終わった後で役立つものだが、最初の1週間を生き抜けられないと無意味になってしまう。

 そんな本気で考えるようなものではないのだけど、久しぶりのフェスで、つい本気で投票してしまったのだ。





個人的には、スプラ2の「サンリオフェス」以来の大失態。


サンリオフェスは、サンリオがスポンサーになって開催されたものなのだけど、どうも最初から「ハローキティを勝たせたい」という要求があったようなのだよね…


おそらくはそのために、マッチングの際に手心が加えられたのだけど、これが露骨すぎて公式が謝罪するまでの騒ぎになりました。

(サーバーの不具合だった、ということになっていますけどね)


今回は、選択肢は悪くなかったのだけど、紹介するキャラクターの寸劇のシナリオが悪かった。

「無人島と言えばリゾートじゃないの?」の一言があれば、これほど道具に偏らなかったと思う。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 バガン入手

03年 カットパイーン

04年 久しぶりの飲み会

04年 出産祝い

05年 せんべい食いたさ

08年 サーバー故障

11年 節電終了

13年 ワープロの日

16年 箱根小涌園ユネッサンに行きたい人へのまとめ(1/3)

16年 箱根小涌園ユネッサンに行きたい人へのまとめ(2/3)

16年 箱根小涌園ユネッサンに行きたい人へのまとめ(3/3)

16年 秋の家族旅行

16年 小田原城

16年 おもしろ歴史ミュージアム・かまぼこの里

16年 ホテルグリーンプラザ強羅


申し訳ありませんが、現在意見投稿をできない状態にしています

vue-tweet-embed で表示していた Tweet が崩れる  2022-08-19 17:10:34  コンピュータ

▲目次へ ⇒この記事のURL

昨日 8/18 の夕方ごろから、仕事で作っていたプロダクトで、Tweet のタイムラインを表示していた部分で画面崩れが起きるようになった。


この時点では、リロードを繰り返すと崩れたり正常だったり。

あ、これは Twitter がウィジェット用の出力を変えたな、と気づいた。


普通は、Web ページに Twitter のタイムラインを埋め込みたければ、Twitter が公式に用意したサイトで作成した HTML の断片を埋め込めばよい。

この断片の中では、widget.js というプログラムを読み込んでいて、このプログラムがタイムラインを埋め込む。


しかし、Javascript のフレームワークである vue ではこの方法が使えなかった。




HTML は、画面を表現するための言語だ。

Javascript は、一般的な意味でのプログラム言語であり、HTML を操作するための機能も充実している。


ここで、Javascript でプログラムを作る際は、「データ操作」と HTML 操作を同時に行うことが要求される。

内部データを計算によって書き換えても、画面に反映されなくてはわからないからだ。


しかし、内部データと画面を常に一致させておく、というのが結構面倒くさい。


vue はこれを解消するフレームワークだ。

HTML とデータのつながりを記述できるようになっている。

そのうえで、Javascript でデータを操作すると、自動的に HTML に反映される。


非常に便利だ。

その代わり、今までのように「Javascript で HTML を操作する」のは禁じ手になった。

vue が書き換えることが前提なので、それ以外の書き換えがあると破綻するためだ。


さて、vue の説明が長くなった。

先に書いた Twitter の widget.js は「HTML を操作してツイートを埋め込むプログラム」であり、vue と相性が悪い。


そこで作られていたのが、vue-tweet-embed というライブラリだ。

これを使うと、非常に簡単に vue 内にツイートを埋め込める。




さて、今回、Twitter が送信するデータの形式が大きく変わったようだ。

widget.js は一緒にバージョンアップされているので問題はない。

しかし、vue-tweet-embed で表示する場合は、問題が出た。


具体的には、vue-tweet-embed のやり方で指定したサイズや、表示の際のオプションがすべて無視される。

縦に長い…とても長い「タイムライン」が表示され、スクロールバーも出ない。


これが冒頭に書いた画面崩れの状況だ。


僕が作っていた環境では、ツイートの冒頭に、以前はなかった「@~さんのツイート」という表示が入るようになった。

これ、noheader という指定で消していたものだが、vue-tweet-embed ではその指定も利かなくなっている。


昨日夕方は「時々崩れる」だったのが、今朝仕事を開始するときには「100%崩れる」状態になっていた。

Twitter 社が、数あるサーバーのすべてで新プログラムに更新が終わったのだろう。


これはどうにかしなくては。




ほぼ一日かけて何とかした。


まず、vue-tweet-embed の使用は廃止。

だましだまし使う方法もあるが、今後も同じようなことが起きては困るからだ。


公式 widget.js で何とかできる環境を構築するのが良いだろう。

先に書いた vue との相性の悪さは、v-once で解決できる。


vue で HTML とデータのつながりを記述する際のオプションで、「一度だけ描画」を意味するものだ。

最初に描画されたら、その後は更新しない。だから、widget.js が書き換えた後の内容が保証される。


あとは widget.js の読み込みをどうするかだ。

本当は、ツイッターの埋め込みを行う部分を指示する HTML などを準備したうえで、「最後に」読み込むと、埋め込みを行ってくれる。


しかし、vue だと埋め込みタイミングがいつになるかわからない。

(vue を使うと、ページ遷移なども画面の書き換えで行い、通信を起こさないようなことが可能になるため)


Twitter 公式に、widget.js 内の「埋め込み」メソッドの呼び出し方が定められていた。


すでに widget.js が読み込まれていることが前提だが、メソッドを呼び出したタイミングで埋め込みを行える。

これは公式に定められたものなので、今後も安心して使えるだろう。


さらに、公式に「widget.js を必要な時に読み込ませるが、読み込みが終わる前に、読み込みが終わったらやって欲しい処理を登録しておく」プログラムも公開されていた



そのままでは vue で使えないが、改造して使うことにしよう。




というわけで、出来上がったのが次のような仕組みだ。


まず、全体としては vue のコンポーネントだ。

このコンポーネントは、ツイートを埋め込むためのものになる。


だから、「埋め込みたい」側の vue プログラムからは、このコンポーネントを読み込んで組み込む必要がある。

この際、v-once タグをつけておいて欲しい。そうしないと、widget.js が書き換えたものが保証されないから。


template の中で、一番最初のタグに ref="tweet" をつけておいて欲しい。

また、ツイートを埋め込みたい部分には、ツイッター公式の埋め込み HTML 断片の、埋め込み部分を書いておく必要がある。

(だって、公式 widget.js は、それを見つけて書き換えるものだから)


あとは、このコンポーネントが読み込まれ、DOM が構築された際に適切なプログラムが動けばよい。

なので、mounted に仕込みを行う。


mounted(){ window.twttr = ((() => { const fjs = this.$refs.tweet; let js; let t = window.twttr || {}; if(t.widgets) return t; // もう関数定義されている js = document.createElement("script"); js.src = "https://platform.twitter.com/widgets.js"; fjs.appendChild(js); t._e = []; t.ready = function(f){ t._e.push(f); }; return t; })()); twttr.ready( () => { twttr.widgets.load( this.$refs.tweet); }); },


先に書いた通り、twitter 公式のプログラムから少し変わっている。


まず、一番重要なのは「widget.js の読み込みタグがなければ、追加することで読み込ませる」だ。

元のプログラムでは、HTML 内にタグがあるかどうかを確認していた。


でも、その追加したタグは、vue によって消されてしまうことがある。

なので、widget.js が読み込まれて関数定義されたかどうかを確認するように変更した。


タグを追加する位置は、元のプログラムでは特定のタグのすぐ後ろ、となっていた。

しかし、v-once された内部にしたいので、「内部の一番最後」に追加している。


あとは、そうした DOM を探し出す方法が vue 向けに変わっているくらいか。



最後に、twttr.ready に「埋め込み」を指示する関数を書いてある。

twttr.ready は、上のプログラムの中で、キューに登録するプログラムとして作ってある。


これ、widget.js が読み込まれた時点で、キューに入っている関数を実行してくれる。

そのうえで、twttr.ready 自体が書き換えられ、キューに登録ではなく「即時実行」になる。


そのため、再度この部分が読み込まれた場合には、新たに widget.js を読み込むこともなく、即時に埋め込みが行われる。




ひとまず、相性が悪い widget.js を、無理やり vue の中にねじ込んだ。

これで、今後 widget.js がバージョンアップすることがあっても大丈夫だろう。


でも、今回もこれだけでなく、文字サイズが変わったり、全体デザインが変わったり、いろいろ変わってるんだよね。


最初の方に書いた noheader が効いていないのは、公式 widget.js では大丈夫だった。

でも、以前は使えた noborder や nofooter は廃止されているようだ。


今回廃止されたのか、以前から実は使えてないのかはわからない。


今後も、「崩れる」ほどではないが、「見た目が変わる」くらいのことはあるかもしれない。



翌日追記

これを書いている「翌日」というのは土曜日。


昨日は、とにかく突貫作業でどうにかしなくてはならなくて、作り上げて日記ネタにした。

今日になって、気になったので、仕事時間外だけど vue-tweet-embed のソースを読んでみた。


驚くことに、構造はほとんど僕が作ったものと同じだった。

公式の widget.js を読み込み、widget.js の埋め込む対象位置を教えるタグを埋め込み、埋め込むための関数を呼び出す。


呼び出す関数が少し機能の違うものだったり、タグの作り方が違ったり、vue の再描画に対する保障方法が違ったり、という違いはあるのだけど、大きくは変わらない。


そうすると、なぜ表示崩れが起きたのかよくわからない。

いろいろな「若干の違い」によるものかもしれない。


また、vue-tweet-embed が広く使われている割に騒ぎになっていないのが不思議だったのだが、これも環境によって動作が違うのかもしれない。



謎はいろいろある。ここに書いたこと自体が、多くの人にとっては無意味なのかもしれない。


しかしまぁ、ライブラリに頼らず問題を自分の手元でコントロールできる状態に置いたことで、今後の保証をある程度得られた、と思うことにしよう。


▲目次へ ⇒この記事のURL

別年同日の日記

04年 お披露目

09年 13日

09年 夏祭り

09年 誕生日

14年 ブレーズ・パスカルの命日(1662)

16年 ゴードン・ベル 誕生日(1934)

20年 視野欠損・経過観察


申し訳ありませんが、現在意見投稿をできない状態にしています

プリンタ購入  2022-07-23 17:47:47  コンピュータ

▲目次へ ⇒この記事のURL

プリンタが壊れ…てないのだけど、半壊くらいになったので新しいプリンタを購入した。


まず、前の機種の状態について。

最近色が変だなー、と思ったので、状態確認のプリントをしたら、黄色と青がちゃんと出ていなかった。

ノズルが目詰まりしている感じ。


まぁ、当然ヘッドクリーニングする。その後状態確認すると、黄色は完全に出なくなり、青もほとんど出なくなり、それまで出ていた赤も目詰まりしているような状態に。

さらにヘッドクリーニングすると、余計に悪化。ついには黒以外がでなくなった。

あ、これダメだ。目詰まりじゃなくて、なんかノズルの機能(インクを送るポンプとか、ピエゾ素子とか)が壊れてるっぽい。


というわけで、すぐに新しいプリンタを探し始め、翌日には購入、翌々日には到着した。


今日は、到着の翌日だ。セットアップして正常に動くようになった。




前に使っていたのは、ブラザーの DCP-J557N だった。

購入したのは7年前だ。


7年も使っていたことに驚いた。

プリンタって可動部品が多く、ゴムやインクなどの自然劣化する部品も多い。

だから、使えても5年程度、と思っていた。


この機種は戦略機種で、6千円で入手した。


ちなみに、インクもブラザーが以前から使っていたものだった。

購入当初から互換インクが多数の会社から発売されており、4色で千円程度。

それで我が家の場合1年くらいは使えていたので、本当にコストパフォーマンスが良かった。



その前に使っていたのは…名誉のために名を伏せるが、有名プリンタ会社のもので、1年以内に壊れた。

さすがに保証期間だったので交換してもらったら、それも1年以内に壊れた。

あの会社はインクタンクに特殊 IC を積んでいたので当時は互換インクもなく、非常に高かった。


なので、この会社のものは我が家的には当面買わない。

大きく状況が変わって評判の良い機種でも出れば買うかもしれないけど。




今回購入したのは、当然のように前の機械の後継機。

…とはいえ、良い特徴のいくつかは失われている。


いくつかの後継機があったが、選んだのは DCP-J926N。

前の機種は6千円で買えたが、2万円弱だった。


コロナで在宅勤務する人が増えて以降、プリンタは売れ行きの良い商品らしい。

値引きして買ってもらうような必要が無くなったので、値引きがない。


そのうえ、ロシア・ウクライナ戦争以降、物価高の影響でプリンタも実売価格が上がっているらしい。

この状況では、2万円というのは悪くない値段のようだ。



で、インクタンクが新開発のものに替わった。

昨年秋に発売されたこの機種から使われるようになったインクタンクなので、まだ互換品が市場に出ていない。

4色で4千円くらい、というのが相場のようだ。


容量の違いなどが明確でないので、単純に高いか安いかは言えないのだけど、まぁ純正品だから互換品よりは高いのだろう。


でも、ブラザーのインクはほかの会社に比べて良心価格だと思っている。

互換インクもそのうち出てくるだろうし。




検討時にはもう一つ候補があって、DCP-J4140N を検討していた。


こちらは大容量インクタンクで、やはり互換品はまだないのだけど、インクの「容量当たり」のコストが低い。

あと、インクが顔料系インクなので印刷が鮮やか。


…でも、インク高いんだよね。4色買うと2万円くらい。


それほど印刷するわけでもないし、人に配布する書類を作るわけでもない。

だから、印刷が鮮やかな必要も、大容量である必要もない。


というわけで、こちらは選ばなかった。

顔料系インクには少し興味があったのだけど。







▲目次へ ⇒この記事のURL

別年同日の日記

02年 免許更新

09年 ゲーム解禁

13年 ○○、Fonera やめるってよ。

14年 高柳健次郎の命日(1990)

15年 夏風邪

18年 LED 電球

19年 のみかい


申し訳ありませんが、現在意見投稿をできない状態にしています

CAPCOM  2022-06-14 16:53:07  コンピュータ

▲目次へ ⇒この記事のURL

Switch でスト2が期間限定無料配布、と聞いて、別に好きでもないのにダウンロードしておこうと思った。


詳細に書くと、CAPCOM ARCADE STADIUM というソフトがあり、これは無料配布している。

というのも、これ自体はプラットフォームであり、ゲームを遊べるわけではないからだ。


で、ダウンロードコンテンツの形で、昔の業務用ゲームを別途購入し、遊ぶことができる。

何も買わないでも、サンプル扱いで 1943 が入っている。縦スクロールシューティングゲームだな。


で、期間限定でストリートファイター2が無料になっている、という話なのだ。

1943 もスト2も、別に好きではない。というか、CAPCOM のゲームをそれほど好きではない。


でも、スト2が歴史的な転換点にあった重要作品であることは認めるし、せっかくだからもらっておこう、と思ったのだ。




ダウンロードして遊ぶ。スト2で選べるキャラ、最初はこんなに少なかったっけ。

ちょっと遊んで終了。対戦格闘自体が、それほど好きなジャンルではないからね。


他にどんなゲーム遊べるのかなー、と、「購入すれば」遊べるゲームのリストを眺める。

あー、そういえばそんなゲームあったなー、と懐かしみながら、各ゲームのタイトルロゴを眺める。


そして、出会ってしまったのだ。「ストライダー飛竜」。


少し上に書いた前言を撤回しよう。CAPCOM のゲームをそれほど好きではない、と書いたが、飛竜は大好きだった。

僕の人生を方向づけたゲームの一つ、と言ってよいくらいやり込んだ。


X68k 版も持っていたし、メガドライブ版は「いろいろ違う」と怒りながらも、やはりやり込んだ。




200円かー。気軽に試してもいい程度の額。

今更昔のゲームは「懐かしい」というだけで、遊ばないのが目に見えているのだけど、買っちゃうか。


よし、買おう。とストアページに行くと、過去にゲームを購入したときに付いたポイントがたまっていた。

200円分くらい、ポイントで買える。実質無料で入手。


これ、CAPCOM の思う壺なんだろうな。



久しぶりに遊んだが、最初の方はそれなりに攻略パターンを覚えていた。

でも、途中から全く覚えていない。コンティニューでごり押ししてエンディングまで行ったが、納得できない。

このゲームはゴリ押しするようなものではなく、美しく踊るものなのだ。


しかし、やはりプレイ感覚の好きなゲームだ。

パターンを思い出しながら、しばらく遊ぶことになりそうだ。




さて、ストライダー飛竜だが、まだソ連が崩壊する前に作られたゲームだ。


ゲームの舞台は「ソ連から帝政ロシアに戻った 2048年」で、このロシアを率いる独裁者は、世界を相手に核戦争を起こそうとしている。

その彼を倒し、世界を救うのが主人公に課せられた使命だ。


…なんか、今書くのが きな臭いな。

まぁ、崩壊するとまでは思ってなかったけど、ソ連がごたごた続きだった時期に作られたゲームだし、この設定を「予言」とまで言うつもりはない。


当時は政府も仮想敵国としてソ連を想定していたしね。


でも、なんかいろいろ考えちゃうのでした。


▲目次へ ⇒この記事のURL

別年同日の日記

02年 眠り姫

06年 CSS

13年 びわ

19年 google photos その後


申し訳ありませんが、現在意見投稿をできない状態にしています

代入の評価順  2022-04-05 20:40:58  コンピュータ

▲目次へ ⇒この記事のURL

Javascript 豆知識。

というか、仕事で重要になった些細なこと。




演算子には評価順がある。

プログラマなら、だれでも意識することだ。


掛け算 * は、足し算 + よりも先に評価される。

でも、括弧 ( ) をつけると、それが最優先で評価される。


1 + 2 * 3 は 2 * 3 が先に評価されて 7 になるけど、

( 1 + 2 ) * 3 なら、1 + 2 が先に評価されて 9 になる、というようなこと。


まぁ、評価順が不安なら括弧で括っとけ、という話でもある。



じゃぁ、次。

6/3/2 という式があった場合、結果は何になるだろう?


これは、6/(3/2) なのか、(6/3)/2 なのか、という問題だ。

答えは、1 だ。(6/3)/2 になっている。


つまり、評価は左のものが先に行われ、右に進む。


Javascript では、累乗は ** で表される。


2 ** 3 ** 2 はどうなるだろう?

答えは 512 だ。2 ** (3 ** 2) が行われている。割り算の時とは逆で、右から順に評価される。



こうした「同じ演算子が続く場合の評価順」のことを、結合性という。

結合性は、演算子により異なる。




さて、本題。


Javascript では、「代入」も演算結果を持つ。

a = 5 という代入式があった場合、これ全体は、代入された値である 5 が結果になる。

そして、これは右から左に評価される。


a = b = 5 という式では、まず b = 5 が評価され、この結果である 5 が a に代入される。



では、次の式はどうか。


var a=0, b=[];

b[a++] = a++;


念のため書いておくと、a++ というのは「a の内容を値とした後で、a を1増加させる」という演算子だ。

a が 0 の時に a++ と書くと、その式自体は 0 なのだが、その後に a は 1 になっている。



さて、代入式は右から評価されるのだから、まず a++ が実行される。

そして、その結果が b[a++] に代入される。


…と、そう思っていた。


でも、結果は [1] になる。配列の 0 番目に、1 が入っている、という状態だ。

先に b[a++] が評価され、その後で a++ が評価されている。




ちなみに、こんな風に式の中に a++ とかを書くのはお勧めしない。


ここではわかりやすい形で書いているけど、実際には await を使った式の評価でバグが出た。

こんな感じだった。


b[a] = await func();

if(!b[a]) return;


func からの戻り値がない場合、それ以降の処理をしない、というようなプログラムだったのだが、実際には func が値を戻したとしても、return されてしまう。


書いたのは僕ではないのだけど、うまく動かないので相談が来た。


await は javascript に並列実行を引き起こすのだけど、その中で a が書き換えられていた。


それにしても、戻り値は b[a] に入ってすぐ次の行で見ているはずで、納得がいかない。

…と、この時点では思った。先に書いたように、左辺の評価は後になると思っていたからだ。


でも、左辺が先に評価されると考えないとつじつまが合わない。

そこで先のプログラムを書き、左辺の評価が先だと知ったわけだ。




Javascript でわからないことがあったら MDN を見ろ、と僕は思っているのだけど、今この記事を書くために確認していたら、ちゃんと書いてあった。

でも、長い文章の中にさらりと入っているので、気づいてなかった。


演算子の優先順位のページに書いてある。

(どこに書いてあるのか探してみよう。見落としていたのに納得してもらえると思う)



・興味深いのは、結合性や優先順位に関係なく、評価の順序は常に左から右になることです。



「計算」には優先順位があるが、「評価」は常に左から。覚えておこう。




▲目次へ ⇒この記事のURL

別年同日の日記

10年 花見

21年 家事のおとも


申し訳ありませんが、現在意見投稿をできない状態にしています

停電  2022-04-04 08:55:25  コンピュータ 家族

▲目次へ ⇒この記事のURL

先日、電力逼迫の話を書いたら、それとは無関係に今朝停電した。


朝4時過ぎ。後で確認したら、4時11分だったようだ。

UPS(無停電電源装置)の4回続けてなるビープ音で目が覚めた。


このビープ音は、電源断を伝えるものだ。

東京電力は頑張ってくれていて、通常なら停電しても数秒で治るし、長くても5分くらい。


UPS は、30秒ごとに4回のビープ音を鳴らす。

何度も鳴り響く。長い停電のようだ。


スマホで情報を確認する。東京電力のページには、停電情報は載っていない。

まだ停電が起きたばかりで、情報掲載に至っていないのだろう。


更に5分ほど。これはどうにかしないといけない、と思って起きる。

UPS に繋がっているとはいえ、使える電力は無尽蔵ではない。


再度情報確認。停電情報が出ていた。鎌倉市で 2100件ほど。

復旧予定は6時。あと1時間半もある。


UPS のステータス表示を見ると、この調子では6時まで持ちそうにはなかった。

無駄なものの電源を落とそう。


たとえば、NAS は急な電源断からは守らないといけないので UPS に繋げているが、停電した状況で動いている必要はない。


WiFi ステーションも UPS に繋いでいるので、ChromeBook でログインすることができる。

NAS に対してシャットダウン指示。これで、電力の使用量が少し減った。


この時点で5時前。6時までならなんとか電源も持ちそうだ。

大抵、こういうのは予告時間少し前には復旧するものだし。


朝の支度を始めようか…と思ったが、IHを使っている我が家では、お湯も沸かせない。

もう一度ベッドに入る




5時55分、断続的だったビープ音が鳴り続けるようになる。

いよいよ電源の残り容量が少ない。


復旧完了時刻を再度見る。6時半に伸びていた。


あ、だめだ。急な電源断で壊れると困るから、家庭内サーバーもシャットダウンしよう。


これで、この日記などを公開しているサーバーも停止した。


で、仕方がない。何もやることないのでまたベッドに入る。




6時半ぴったりに、通電が始まった。

復旧したようだ。


僕は主夫なので、まずは朝の支度。

炊飯器もタイマーでが止まってしまったため動いていない。

炊飯を開始し、一日分のポットのお湯を沸かし、朝ごはんの支度をする。


並行して、サーバの復旧作業。

サーバは2台ある。


1台は土台となるホストOSは起動したが、その上で動くゲストOSが起動しない。

このゲストOS が普段仕事で使っているものなので、これでは困る。


サーバに直接コンソールを接続し、virsh start させる。ついでに virsh autostart も設定しておく。

(前回起動したのはいつだっただろう。自動起動の設定を忘れていたようだ)


もう一台、このページを載せている、公開用サーバが動いていない。

その土台にもログインできない。なんで? ややこしそうなのでひとまず置いといて、朝ごはんの支度を続ける。


ある程度朝ごはんができたところで、再度設定作業。

どういうわけか、サーバー自体がうまく起動できていなかった。

強制的に電源を落として入れ直しても動かない。BIOS 起動すらしない。

壊れたか? 焦る。


一度電源をプラグから抜いて、再度差し込んだら問題なく起動した。

あぁ、時々あるやつだ。問題なし。


こちらは、ゲストOSまで自動的に起動した。7時半。


というわけで、このサイトは、6時から7時半の1時間半ほど、停止していました。

こんな時間に見ていた人がいるかわかりませんが、ご迷惑をおかけしました。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

別年同日の日記

12年 言葉の定義

13年 科学館めぐり

14年 ジョン・ネイピアの命日

15年 ジョン・ネイピア 命日(1617)

16年 冒険遊び場・花見

18年 ピューロランドで誕生日

18年 ピューロランドの秘密

19年 風邪が続いています


申し訳ありませんが、現在意見投稿をできない状態にしています

BABA IS YOU  2022-02-27 18:19:16  コンピュータ

▲目次へ ⇒この記事のURL

あ、ちょうど2年前ではないか




ちょうど2年前、BABA IS YOU というパズルゲームを購入した。

ゲームの説明は、上のリンク記事で。


2年たって、やっとすべての面をクリアできた。



…いや、厳密にはまだ終わっていない面もある。

「マップコンプリート」で「THE END」の状態に持っていけた、というのが正確な説明で、一応ゲームの目的は果たしたことになるのだけど、まだやることは残っているから。




パズルゲームは好きなのだが、このゲームは普通のゲームとは違った。


2年もかかったのは、もちろん難しかったからだ。

ただ、「難しい」のかというと、そうでもないように思う。


普通のパズルなら、「難易度」というような指標が、なんとなくではあるが存在する。

しかし、BABA IS YOUはそういう尺度に当てはまらない気がするのだ。


難易度が普通は数値で示せるとしたら、なんか虚数軸方向に伸びてしまった感じ。




パズルゲームのネタバレをするわけにはいかないので、別の話で例えよう。


ファミコンの初代「ゼルダの伝説」には、「裏」と呼ばれるステージがある。


エンディングを迎えたものが遊べる、もう一つのゼルダの伝説。

ここに、今でも感心するギミックが用意されていた。


ゼルダの迷路には、明らかに「なにかある」と分かるのに、入れない部分がある。

これは、隣から爆弾を使って壁を壊すことで、入れる。


これはもう、ゼルダを遊ぶ上での常識だ。長い旅を終えて、エンディングを迎えたものにとってはそうなのだ。

にもかかわらず、「裏」では、絶対に何かあるのに、散々周囲の壁に爆弾を仕掛けても入れないところがある。


これ、プログラムを作ってあるにもかかわらず、「裏」になるまで登場しない新ギミックなのだ。

壁に向かって歩き続けると、すり抜けることができる。


「壁は爆弾で壊すもの」という常識を作り上げておいて、その常識とは違うことを求める。

「裏」は、面データなどが変わっただけのゲームだと思って遊び始めていたら、ここでまさかの新ギミック登場なのだ。


常識というのは、視野を狭くする盲点でもある。

こういうことをされると、なかなか正解に辿り着くことができない。




BABA IS YOU は、こんなことの繰り返し。


パズルなのに、ある面で使った解決方法はほかの面で役に立たない。

それどころか、「常識」を形成された後で、それを疑わないといけないような面を用意される。


だからなかなか正解にたどり着けない。

一週間も同じ面で悩み続けていると、全然 BABA IS YOU を遊んでいなかった妻が横から「こういう風にすればいいんじゃないの?」と、常識外れの解法をよこして、それが正解だったりする。


なんか、難しいとかそういうゲームじゃないのだ。

ゲームの根底にある常識を疑わないといけないのだけど、遊んでない人には常識が形成されていないから簡単に解けたりする。


こんなのが、200面以上ある。


まぁ、2年間 BABA IS YOU ばかりをやっていたわけではない。

忙しくて一切ゲームをやってなかった期間もあるし、サクナヒメやグノーシア、GOLF STORY なんかを遊んでいた時期もあった。


(GOLF STORY については日記に書いた気がしていたが、書いてなかったようだ。

 面白かったけど、人に勧めるほどのゲームではなかったからな…

 サクナヒメは、すごく話題になったゲームなので、わざわざ僕が書く必要はないと考えて書かなかった。)


しかし、他のゲームを遊んでいても、一息ついたら BABA IS YOU に戻ってくる、という感じだった。




2年前の紹介記事にも書いたのだけど、内容をちょっとおさらい。


基本的には、倉庫番タイプのパズルゲーム。何らかの「物体」を、主人公キャラで押したり引いたりしながら面クリアを目指す。


ただ、この「物体」として重要なものに、「単語」があって、単語を組み合わせることでゲームのルールを変更できる。


主人公も、面クリア条件も、障害物も、ルール組み換えの対象だ。


最初の方の面は、この組み換えの楽しさを知ってもらうためか、大味な面が多くなっている。

面クリアの方法で「別解」がいくつでも作れたり、画面上に主人公を大量発生させて、数の暴力で障害を乗り越えたり。


でも、こうした過程でゲームのルールを把握したころには、本格的なパズルゲームになっていく。


なにせ、200以上ある面で、「同じような解き方」の面がほとんどないのだ。

ある面で使った方法は、別の面では役に立たない。


遊ぶ方にも歯ごたえのあるゲームだが、それほど多くのパターンを用意した作者側に舌を巻く。




倉庫番なら、ルールの中で「荷物を動かすルートを考えて」「そのルートを確保する手順を考える」というような思考で解くことができる。


しかし、BABA IS YOU は上に書いたように、ルールが書き換えられてしまう。

目指すべきゴールがどこにあるかもわからない状態にされて、ゴールから逆算して考える、ということもできない。


それでも、「何がゴールとなるべきか」も、遊んでいるうちにだんだんわかってくる。

面ごとにゴール条件は異なるとは言っても、「主人公に設定されたオブジェクトが、ゴールに設定されたオブジェクトに重なること」という基本は変わらないのだ。


ゴールが分かれば、そのゴールを実現するためのオブジェクトの動かし方を考える段階に入り、倉庫番と同じような方法で解ける。


しかし、BABA IS YOU にはもう一段階先の難しさがある。


ルールを作る「単語」は時々追加され、その単語の意味をゲーム中で十分に把握する必要があるのだ。

ここで、先に書いたような「常識」の形成が…ミスリードするように行われる。


間違った常識は、ゲームの障害になる。

先に「ゴールが分かれば」、後は解ける、と書いた。しかし、間違った常識により、この過程が阻害されるのだ。



オブジェクトは、常識外の動作をする。

常識外なので、最初は「これ、バグじゃないの?」とすら思う。


だけど、バグじゃないのだ。間違っていたのは自分の常識の方。

試行錯誤の末にクリアして、常識が上書きされ、より正しいルールを理解できるようになる。


もちろん、そんな面ばかりではない。そこまでに作られた常識をうまく組み合わせるだけで解ける面も多い。

…もっとも、「うまく組み合わせる」のが難しいのだけど。




まぁ、作った側も「難しい」だろうことは予期しているのだろう。

全ての面を解かないでもよいようなゲーム構成にはなっている。


面は、様々な「テーマ」ごとにエリア分けされていて、エリア内の半数くらいの面を解くと、次のエリアが表示されるようになっている。


エリア内の面も、解けないならあきらめて、別の面を試せるようになっている。

だから、先に進む目的では、実はそれほど難しいゲームではない。


僕が2年もかかった、というのは、あくまでも「マップコンプリート」を目指していたため。

先に書いたエリア内の面を全部クリアすると「エリアコンプリート」となり、用意された全部のエリアをクリアすると「マップコンプリート」になる。


つまりこれは、基本的に用意された面の全面クリアを意味する。




そう、「基本的に」用意された面しか、まだクリアできていない。

ゲーム上、たくさんの「隠し面」があるのだ。


隠し面は、ゲーム上のいくつかの面で、「ゴールする」以外のことを行うことで現れる。


…いくつかの面には、面を解く以外にも、まだやることがあるのだ。

詳細を書くと、その方法を見つけたときの衝撃を奪ってしまうので書かないけど。


この「別のことをする」のも、面ごとにやるべきことが異なる。

でも、気づいてしまえば、やるべきことは見えてくるように作られている。


そうなった時に、もっと大きな別のパズルの存在に気づくだろう。



…驚かされっぱなしのゲームだ。

こんな飛びぬけた発想のゲームを良く作った、と思うし、その「発想」が、発想どまりにならずに高いレベルでまとめ上げられていることが素晴らしい。





なんかもどかしい書き方になっているな…パズルだからネタバレしてはつまらない。


パズルゲームが好きな人には、非常にお勧めなゲームだ。

ただし、完全に自分の力で解こうと思ったら、すごく時間がかかる覚悟は必要だ。


どの面も、「解けた」瞬間には驚きがある。

その驚きこそが楽しいゲームなので、時間をかけても攻略サイトなどを見ずに解くことをお勧めする。


先に書いたように、僕もまだやるべきことを残している。



…そして、先日「追加面」が無料配信されたんだよね。

主に「開発中で没にした面」を揃えているようだけど、また 200面以上あるらしいですよ。


こちらは没にした面、というだけあって、本編を知っていると楽に解ける面も多い。

とはいえ、そこは BABA IS YOU だ。没面でも驚くような解き方が多い。


追加面はまだ少ししか遊んでいない。先は長そうだ。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 2/27

12年 おゆうぎ会

15年 WING WAR

20年 BABA IS YOU


申し訳ありませんが、現在意見投稿をできない状態にしています

node.jsの2つのイベント処理  2022-01-27 17:16:47  コンピュータ

▲目次へ ⇒この記事のURL

仕事で node.js を使用しているのだが、思わぬところで引っかかったので記しておこう。


…と、いきなり話を始めてもわからないので、前提知識から。


node.js は、サーバ側で Javascript を使用するための仕組みだ。


そして、Javascript は「Webブラウザで使う」ことを前提に設計された言語だ。

設計当時の OS は、Windows3.1 と MacOS 8 …


どちらも、今のマルチタスクとは違って、「アプリケーションの善意」でマルチタスクを実現していた。

(OS が割り込みで CPU 時間を管理するのが今の方式だが、Win3.1 や MacOS 8 は、アプリケーションが「短い時間で OS に処理を返す」ことを前提にしていた。

 処理を返さないプログラムがいると、全体の動作が停止し、破綻した。)


いきなりすごい昔話が始まったが、その時代に設計された「アプリケーション内の組み込み言語」として、長時間の処理を「させるわけにはいかなかった」。


そこで、Javascript では「イベント駆動」という仕組みを使った。

画面がクリックされた、ボタンが押された、マウスカーソルが特定の領域に入った、など、あらかじめ設定した「イベント」が起きた場合に、指定したプログラムを呼び出してもらう。


イベント駆動でないなら、プログラムが動く条件を調べるところから自前で作らないといけない。

そして、条件を調べるためには、ユーザーがいつ押すかわからない「ボタン」が、押される瞬間を待ち続けないといけない。


…ここで「待ち続ける」というのがダメなのだ。

先に書いたように、短い時間で OS に処理を返さないと、全体が破綻するのだから。



そんなわけで Javascript はイベント駆動だし、なにかを「待つ」必要のある処理を「書けない」ように設計されている。

待つ必要がある場合には、その事象が起きた場合のイベントがあらかじめ用意されているから、そのイベントに対して処理を設定するのだ。


結果として、Javascript のプログラムはイベントを待って少しだけ処理する、というプログラムの断片だらけになる。




ブラウザ側なら、それでいいだろう。


ブラウザはユーザーインターフェイス(UI) の塊で、ユーザーが何かしたら、このプログラムを動かす、ということの連続でできている。


Javascript の組み込みイベントも、そうしたブラウザに合わせて設定されている。

この設定はブラウザメーカが勝手に作っているわけではなく、ECMA という団体で標準化されている。

だから、どこのブラウザでも同じ Javascript プログラムが動く、はずだ。


(実際には、すでにメンテナンスされていない IE とかは仕様が古すぎて最近のプログラムが動かなかったり、Chrome と FireFox で若干の仕様差があったりする。)


話しは戻って node.js なのだが、これはサーバ側で Javascript を動かす仕組みだ。

そして、ECMA の定めるイベントには、サーバで必要とするような事象が十分に考慮されていない。



先に書いたように、Javascript はイベント駆動だ。イベントなしにプログラムを書くことは、まぁできなくはないのだけど、やりづらい。

でも、サーバ向けのイベントは用意されていないし、そもそもサーバで作りたいプログラムは、ブラウザ側の UI と違って非常に多岐にわたる。


そこで、node.js では「ユーザが自由にイベントを拡張できるライブラリ」を作った。これは標準ライブラリとして、node.js を使える環境では必ず使える。

そして、多くの標準ライブラリで、このライブラリを使ったイベント処理を実現している。


なかなかうまい仕組みで、サーバ上でのプログラムを、違和感なくイベント処理で作ることができる。




さて、ここからが今日の本題。


Javascirpt に組み込みのイベントと、node.jsの標準ライブラリが提供するイベント。

同じ「イベント」の仕組みなので同じような動作をする、と思ってプログラムをしていたら、全くそうではなかったのだ。


気づかずに落とし穴にはまってしまった。

何か違う、と気づいてから情報を求めて探し回ったが、この違いに言及している日本語の記事には出会えなかった。


英語で探していてもほとんど情報がなく、「少し違うよ」程度に書かれている記事はあっても、具体的な情報がない。


最終的に、node.js のプログラムを読んで違いを理解した。



具体的には、次のようなプログラムが問題になったのだ。



const stream = fs.createReadStream("sample.text", {encoding:'utf8'})
const reader = readline.createInterface({input: stream})
const headline =  await new Promise((resolve) => {
    reader.on('line', (line) => {
        reader.close()
        return resolve(line.trim())
    }).on('close', () => {
         return resolve('')
    })
})


これはプログラムの断片で、ライブラリとして標準提供されている fs と readline を必要とする。


短いのに Javascript らしい、非常にわかりにくいイベントプログラムになっているので説明しよう。


まず、stream を作っている。

これは、ファイルを読み込んで、読み込みに成功すると、「読み込んだ」というイベントを起こしてデータを渡してくれる。

ここで、特に指定が無ければファイルの頭から終わりまで、読み込みバッファ(指定が無い場合は 64Kbyte)毎に勝手にデータを読み続けてくれる、というのがミソなのだが、ここではあまり意識する必要はない。


この stream を入力として、reader を作っている。

stream で流れてくるデータを、行ごとに分解して、できた行ごとにイベントを起こしてデータを渡してくれる、一種のフィルタだ。


このプログラムでは、この reader に対して2つのイベント処理プログラムを設定している。


line は読み取った行を渡してもらうイベントで、行を受け取ると reader を終了し、行を結果として返す。

(resolve は結果を返す仕組みだが、詳細後述)


また、行が1つもないと…つまり、0バイトのファイルだと、line が来ないで close が来る。

この場合は「空文字列」を結果として返している。


つまりは、テキストファイルの最初の行を取り出すプログラムになっている。



さて、resolve という変わったやり方で結果を返しているのは、これらのプログラム全体が、

Promise という関数の中で呼び出されているためだ。


これもイベントを作り出す仕組みで、「何かを待つ」必要があるときに使う。

先に書いた通り Javascript では何かを待つことはできないのだが、Promise は最近作られた巧妙な仕組みだ。


Promise は、Promise オブジェクトと呼ばれるデータを返す。この時に待ち時間は発生しない。


そして、Promise オブジェクトは、渡された後でも値が変化する、という何とも奇妙なものだ。


最初は「未解決」という状態になっている。

その後、resolve を呼ばれると「解決済み」となり、そのとき resolve に渡された値を読み出すことができる。



await という制御命令は、Promise オブジェクトを引数とする。


そして、await があると、Javascript はその前後でプログラムを分割する。

(以降のプログラムを、勝手に別の関数にまとめると思って欲しい)

そして、await 命令でいったんプログラムの実行を終了してしまう。


await は「Promise が解決した」というイベントを待ち、イベントが発生すると以降のプログラムの処理を始める。

これにより、「待つ」という動作が、見事にイベント駆動に置き換えられ、短い時間で処理を終了する、という Javascript の理念を守ることができる。




ここで、もう一つの Javascript の特徴を説明しておこう。

このあとの話で必要になるからだ。


Javascript の大きな特徴は2つある。一つは、ここまでに書いた「イベント駆動」だ。

もう一つが「シングルスレッド」。


Windows などの OS は。複数のプログラムを同時に動かすことができる。

これを「マルチスレッド」と呼ぶ。


これに対して、Javascript はシングルスレッド。1つのプログラムしか動かせない、という意味だ。

Javascript はイベント駆動で、このイベントはブラウザの場合なら、ユーザーの操作などで引き起こされる。


マウスを動かした、ボタンをクリックした、などだ。


でも、「イベント」が起きても、すぐにイベントの処理プログラムが動くわけではない。

すでに動いているプログラムがあるなら、そのプログラムが最後まで実行終了するまで待たされる。


多数のイベントが有るときは、イベントは処理待ちの「キュー」に貯められる。

そして、動いているプログラムがないときに、順次処理されていく。


複数のプログラムを同時に動かす、というのは、コンピューター的には実は結構「無理している」処理で、無駄が多いのだ。

それに対して、1つのプログラムを動かすだけなら、その仕事に専念できるので効率よく動かすことができる。


シングルスレッドと、必要なときには仕事を「溜めて」おけるイベントキューの組み合わせで、効率よく仕事をこなせる。

これが Javascript の特徴で、node.js が高速だと言われる理由でもある。




さて、話を戻す。先程のプログラムでは、2種類のイベントが出てきた。

Promise によるイベント処理と、reader(readline) によるイベント処理だ。


このふたつが全然違うことで問題が起きる、というのが今日の話のテーマだ。



先程描いたように Promise はプログラムを小さな単位に自動的に区切り、1回のプログラム実行時間を短いものにする。


await new Promise の前と後ろでプログラムは区切られる。

後ろのプログラムは、resolve が実行された後で実行される。


ここで、resolve が「以降のプログラム」を動かすわけではない、ということにも言及しておこう。

resolve は、promise オブジェクトを「解決済み」に変更する役割しか持たない。


resolve はイベントをキューに積むだけで、「解決」したときの、await 以降のプログラムを動かすわけではない。

実際に await 以降のプログラムが動き始めるのは、また別のタイミングなのだ。


ところが、reader によるイベント処理はそうなっていない。

そのため、先に書いたプログラムは正しく動作しない。


具体的には、reader.close() に落とし穴がある。

これが resolve と同じように、close イベントを発生させるだけで実際の処理は後回し、であればよいのだが、実際には reader.close() 関数呼び出しの中で、reader.on('close', ~ に書かれているプログラムが呼び出されてしまうのだ。


その結果、イベント処理は「最小の処理時間」を実現するのではなく、実行時間を引き延ばすことになっている。

さらに、line イベントのプログラムの「途中で」close イベントのプログラムが始まってしまうことで、close イベントの resolve が先に動いてしまう。

Promise はそこで解決してしまうため、行のデータを渡す、という一番大切なことが実現されない。




なぜこんなことになるのか。


node.js の提供する「イベントを実現するライブラリ」は、実際にはイベント「風」のふるまいを行うだけで、Javascript のイベントとは全く別の動作をするためだ。


Javascript のイベントは、Promise の resolve のように、「イベントが起きた」という記録だけを行い、そのイベントに紐づいた処理は後で起動される。


しかし、node.js のイベントライブラリは、「イベントが起きた」ことを伝えると、そのことを伝える関数の中で、イベントに紐づいた処理を呼び出してしまう。


Javascript はシングルスレッド…プログラムの途中で別のプログラムが動き始めることは無い、と保証されている言語なのだが、この仕組みだと、その前提さえ崩れてしまう。


(イベントを起こすと、そのイベントによって割り込みが起こったような挙動になる)




node.js のイベント標準ライブラリの名前は EventEmitter 。


これ自体は非常に便利なものだし、批判したいわけではない。

言語の持つ仕組みではなく、その言語自身で書かれたライブラリとしてイベントを「疑似的に」実現しているので、挙動が違うのも仕方がないところ。


ただ、使う上でこの知識を持っていないと、思わぬところで謎の挙動に悩まされることになる。



最初に書いた通り、日本語でこのことを解説する記事を見かけなかったので、ここに記しておく次第。

(EventEmitter の使い方、というような記事は多数あるのだけど)



▲目次へ ⇒この記事のURL

別年同日の日記

03年 おでん

17年 ザ・ハウス・オブ・ザ・デッド


申し訳ありませんが、現在意見投稿をできない状態にしています

続・グノーシア  2022-01-11 13:55:03  コンピュータ

▲目次へ ⇒この記事のURL

グノーシア、というゲームについては、購入して少し遊んだ時点で一度書いている。


我が家では、家族全員が気に入って繰り返し遊んでいる。

いち早く「完全クリア」した長女は、その後もわずかな暇があるときに遊び続けている。


(まとまった時間があるときはスプラ2やるとか、使える時間に応じてゲームを変えている。

 グノーシアは、1回5分程度から遊べる)


さて、僕も少しづつ遊び続け、年末年始の休みでやっと完全クリアに至った。

やはりいいゲームだった。感想を書いておこう。


ここで「完全クリア」と書いてあるのは、単にエンディングを見たのではない、という程度。

本当は、きっとまだ「完全」ではないだろう。




グノーシア自体は、人狼を元にしたゲームだ。

閉鎖された宇宙船内で、人間に感染し、人間に敵対する「グノーシア」と多数決で戦うゲーム。


見た目は人間と変わらないため、外見からは判別できない。


ただし、船に一人だけ乗り込んでいる「エンジニア」は、船が空間転移…定期的に行われる、ワープ航行の際の特殊な状況を利用して、一人だけグノーシアかどうかを検査できる。


しかし、それで誰がグノーシアかを確定できるのは、当のエンジニアのみ。

グノーシアは「嘘をつく」ことができるため、エンジニアを名乗って情報を混乱させる。

本人以外は、情報が本物か偽物かもわからない。



ゲーム上、5回の「話し合い」が1ターンで、ターンごとに投票して一人の「コールドスリープ」を決定する。

ここは人狼に比べて穏やかなところ。人狼では投票で「処刑」するのだが、眠ってもらうだけだ。


そして、コールドスリープ状態にあるものは、これも船で一人だけの「ドクター」が検査して、人間かグノーシアかを判別できる。

もちろん、ドクターを名乗って情報を混乱させるグノーシアもいる。



グノーシアも、ただやられるのを待つだけではない。

ターンの最後に、一人だけ「消滅」させることができる。


空間転移の際の特殊な状況を利用し、人間を一人、完全に消し去るのだ。


このほか、絶対に人間であると互いに保証できる、二人一組の「留守番」、人間だがグノーシアを崇拝し嘘をつく「AC主義者」、存在していることが異常で、最後まで残ると宇宙を崩壊させる「バグ」など、いくつかの役職があり、それらの存在が状況を複雑にする。


ただし、ここまでは単に舞台や役職名を置き換えただけの人狼にすぎない。




グノーシアには、ストーリーがある。


いや、ストーリーと言ってよいのかどうか…世界観、という方が良いかもしれない。


グノーシアとは何なのか。なぜ人間に敵対するのか。

なぜ、どうやって人間を「消滅」させるのか。


1回のプレイは、グノーシアを全員眠らせて人間が勝利するか、もしくはグノーシアが過半数を占めて船を乗っ取るかで終わる。


しかし、時々この世界についての情報の断片を入手できる。

それは、登場人物の生い立ちだったり、全く意味の分からない…でも、すべてが明らかになった時に納得できるイベントだったりする。


少しづつ違う設定で繰り返し遊ぶことになるのだが、これも「そういう世界観」の一部だ。

プレイヤーと、もう一人の重要キャラクターだけが、並行宇宙を彷徨い、繰り返し同じ時間を過ごす能力を持っているのだ。


なんで? その能力は何のためにあるの?

それも謎の一つになっているが、ストーリー上やがて解き明かされる。



そして、多少ネタバレになってしまうが、「際限ない繰り返し」から脱出することが、ゲームクリアの条件となる。

それを達成するとエンディングが流れ、「1周目」のクリアとなる。


…のだけど、先に「完全クリア」と書いた通り、1周目クリアは完全クリアではない。

まだ謎がたくさん残っているし、ひとまずのエンディングではあるが、未解決問題も残っているのだ。



またネタバレで申し訳ないが、プレイヤーがゲームを始めるときに、性別を選ぶことができる。

ゲーム上性別はほとんど関係ないのだが、ストーリー上わずかな影響を与える。

このため、すべてを知ろうと思ったら、少なくとも2周クリアする必要がある。


(性別は三種類。男、女、汎、になっている。先にクリアした長男によれば、汎専用のイベントは用意されていないらしい)



そして、2周目をすべて終わらせる前のどこかで、1周目で未解決だった問題が解消される。

これが本当のエンディングだ。


すべての伏線が収束して綺麗に閉じる。

まぁ、ゲームとしての面白さを優先しているので、ストーリー的な荒さは多少あるのだけど。



実は、子供のプレイで先にこのエンディングは見てしまっているのだけど、自分で見るとまた違った印象になった。

それまでの過程…断片情報の積み重ねによる世界観の把握があるかどうかで、意味合いが変わってくるためだ。



なので、多少のネタバレがあってもこのゲームは楽しめる。

家族で遊ぶのにもお勧め。




さて、人狼面倒くさそう、という人向けに、このゲームが人狼と違って面倒くさくはないことを書いておこう。



相手が人間ではなく、コンピューターの動かすキャラなので自分のペースで進められる、というのは大きな要素の一つだ。

これは遊び始めてすぐの日記でも書いた。



でも、それ以上に、本物の…対人の人狼とは違う気楽さがある。

ゲーム進行に伴い、自分の能力があがり、使えるコマンドが増えるのだ。


対人の人狼では、「なんか嘘くさいな」と思っても確証を持つことが難しい。

でも、グノーシアでは自分の能力値次第では、相手が「嘘を言っている」と気づくことがある。


確実に嘘をついている、と分かるキャラがいて、そのキャラと妙に仲の良いキャラがいれば、それがグノーシアのグループではないか、と芋づる式に見つけ出すことができる。

(グノーシアが複数人いる場合、グノーシア同士は誰が仲間か知っている)


もっとも、だからこそ人間なのに嘘をつく「AC主義者」などの配役もあるのだけど、AC主義者はグノーシアが誰かは知らないため、微妙な反応の違いで見分けられたりするのが、また楽しい。


コマンドも、最初の内は「疑う」「かばう」「同調する」などの簡単なものしか使えないのだが、能力が上がるにつれて「反論する」「同意を求める」「哀しむ」「絶対に敵だ」…果ては「土下座する」なんてものもあり、適切に使うことで楽にゲームを進められるようになる。


1回のターンは5回の話し合いから成るのだが、ある程度能力があがってからの僕の1ターン目はこんな感じ。

自分はエンジニアでやった場合。


・名乗り出ろ 留守番

・名乗り出ろ ドクター

・役割を明かす エンジニア

・人間だと言え

・(流れに任せて静観)



「名乗り出ろ」は、役割を持つキャラに、役割を明かすように指示するコマンド。

自分の能力値が低いと誰も名乗り出ないこともある。

(役割は重要なものなので、明かすことでグノーシアに消される危険があるため)


留守番は互いに保証する必要があるため、必ず「人間」2名が名乗り出る。

ドクターとエンジニアは、偽物も名乗りを上げる。


そして「人間だと言え」は、全員に「自分は人間だ」と言わせるコマンド。

グノーシアは嘘をつくことになるので、嘘に敏感な…自分も含め、能力値が高いキャラなら嘘を見抜くことで、グノーシアに気づくことができる。


自分がエンジニアの場合、この後怪しい人間を調べていくことになる。

もっとも、自分がグノーシアを知ったとしても、それを他のキャラに信じてもらうのが大変なのだけど…




ちなみに、上の戦略を十分に能力値がないことにやると、目立ち過ぎてグノーシアに狙われたり、怪しまれてコールドスリープさせられたりする。


逆に言えば「育てたキャラなら無双できる」のであり、一人用のコンピューターゲームらしい気楽さが、そこにある。


人狼が面倒くさいと思うような人でも楽しめる人狼。よくできている。



ちなみに、登場人物は自分を含めて15人。

コンピューターが担当する14人は、細かな性格付けができていて、同じような状況でも人によって反応が違ったりする。

この性格を覚えるのも、ゲームを勝ち抜くためのコツで、対人戦だったらそんな簡単にはいかないだろう。


(人間には当然性格はあるが、「こういう性格だからこういう行動をとる」と言えるほど単純ではない。

 グノーシアはゲームなので、各人の性格による行動の違いはあるが、各人が予想外の行動をとることは少ない)


2周もやると、それらの性格付けも含め、キャラクターが愛すべきものになっていく。

最初の内は怖かった謎のキャラも、様々なバックグラウンドがあるだけで、みんな優しいいいやつなんだ。




何度も遊べるゲームシステム、よくできた世界観、綺麗に収束するシナリオ、生き生きとしたキャラクターの性格付け…


非常によくできたゲームです。

改めて、お勧めです。



▲目次へ ⇒この記事のURL

関連ページ

BABA IS YOU【日記 22/02/27】

別年同日の日記

04年 住宅展示場

06年 自宅で新年会

17年 アントニー・ホーア 誕生日(1934)


申し訳ありませんが、現在意見投稿をできない状態にしています

Windows 11  2021-12-22 17:48:30  コンピュータ

▲目次へ ⇒この記事のURL

メインマシンが、Windows 11 にアップグレード可能になったので入れてみた。


アップグレード可能、という通知が来たのは先週の末。

週末に入れてみようかな、と思ったけど、仕事にも使っているマシンだし、年末にするか…と保留した。



今週頭、通常の Windows Update で再起動を求められたので再起動。

そしたら起動後の最初の画面で、「Windows 11 をお勧めします」って言われた。



拒否するか取得するかの2択。

今から仕事でこのマシン使うんだよ。とりあえずは拒否。


すると、今はまだ作業続けられるよ、ダウンロードして後で入れればいいよ、って言われる。

じゃぁ、入手だけしておくか。




確かに、とりあえず作業は続けられた。

でも、ファイルダウンロードしてから2日も放置していたら、「アップデートのため再起動しましょう」とうるさい。


まぁ、アップデートしてもいいか。

昼休みでご飯食べる間に再起動。



戻ってきたら、無事 Windows 11 にかわっていた。




感想。


ひとまず、何も変わらない。



もちろん、いろいろと変わっているのよ。

スタートメニューは一新されたし、タスクバーも一新された。


でも、スタートメニューって、僕はそれほど使わない。

だから、変わってもあまり影響ない。



タスクバーは、Quick Launch を使えなくなったのが地味に痛い。

Quick Launch は Windows 95 から親しんできた。


…でも、今調べたら XP ですでに消えていたのね。

消えても、設定で表示できた。



Win 7 の時にいよいよ消えた。設定からも表示方法が消えた。

でも、ちゃんと設定する方法があって、Win 10 でも使えていた。


それがいよいよ Win 11 で完全消滅した。


じゃぁどうしたかというと、Win 7 で消えたときに、ちゃんと代替方法が用意されたから消えたのね。

「タスクバーにピン止め」だ。



実のところ、Quick Launch とピン止めは似て非なるものだ。

だからこそ、慣れ親しんだ QUick Launch の方を愛用していた。


でも、ないなら仕方がない。

Win11 に切り替える前に、無くなるのを知ってピン止めに慣れるようにしていた。


まぁ、2日ほどしか慣れる期間がなかったのだけど、違うと言っても用は足りる。

不便になった部分もあるが、便利になった部分もある。だから良しとしよう。




結果、今のところ Window の角が角丸になっている、というのが若干の違和感があるだけで、普段の作業フローには何の影響も出ていない。


角丸なんて、数日使えば慣れるだろう。その程度の違和感だ。


Windows 11 には楽しみな新機能もあるが、そうしたものはまだ提供されていない。

この点でも、今までと何も変わっていない。


まぁ、大き目なアップデートではあったが、普通のアップデートとそれほど変わらなかった、というだけの話。




▲目次へ ⇒この記事のURL

別年同日の日記

04年 冒険百連発?

11年 リモコン当たった

14年 Scratch 2.0

16年 ここらでコラムス


申し訳ありませんが、現在意見投稿をできない状態にしています

i-mode終了  2021-11-30 17:56:02  コンピュータ

▲目次へ ⇒この記事のURL

本日をもって i-mode のサービス終了、らしい。

ついさっきネットのニュースで知った


もっとも、まだ継続していたのか…という気持ちの方が強い。


仕事上の秘密事項もあってあまり多くは語れないが、i-mode は人気が出る前から、公式サイトの構築などをさせていただいた。

フリーのプログラマーになって、最初の「儲かった仕事」だった。

(それ以前は食い扶持を稼ぐのに必死)



上にリンクした記事でも、ピークが 2010年ごろと書いてある。

僕もその頃までは、i-mode …僕の場合は EZweb の方が仕事の中心だったのだけど、携帯コンテンツを作っていたように思う。


2018年に、これらの携帯コンテンツから手を引いた

メンテナンスコストの方が、儲けより大きくなったためだ。


それから3年ほどで i-mode 自体が終了したことになる。

一つの時代が終わった気がする。



▲目次へ ⇒この記事のURL

別年同日の日記

07年 成長記録

09年 fon 導入

17年 モノポリー


申し訳ありませんが、現在意見投稿をできない状態にしています

グノーシア  2021-11-25 18:25:39  コンピュータ

▲目次へ ⇒この記事のURL

Nintendo Switch のゲーム、グノーシアを購入した。


発売したのは昨年の4月、そもそもこれは移植版で、最初に作られた PS Vita 版は2019年発売だそうだ。


しかし、数日前までこの作品の存在を知らなかった。

たまたま読んだ記事で紹介しており、「すごく面白そう」と思って早速購入、遊んでみたのだった。


購入は火曜日、勤労感謝の日だったのだが、その日に2時間ほど遊んだ後、仕事が忙しくて遊べていない。

しかし、子供たちが Switch に新しいゲームが入っていることに気づき、遊び始めて熱中している。


1人用のゲームなのだけど、周りで見ている人も参加できるようなものなので、他人のプレイでも口を出してしまうのだ。




先に書いたように古い作品なので、レビューは検索すればいくらでも出てくる。

だから詳細は書かないでおこう。そもそも、先に書いたように2時間しか遊んでいないので深い話は書けないし。


ゲーム内容は人狼だ。

あの「心理戦」を、コンピューター相手に行う。


人狼とか、人狼をモチーフにしたゲームはそこそこ遊んだことがあるが、嫌いじゃないけど面倒くさい、と思ってしまう。

心理戦だから人数が必要だし、人数が増えると時間がかかるし、長時間の心理戦は消耗する。



で、グノーシアはコンピューター相手の一人用ゲームなので、自分のペースで進められる。

1ゲーム 15分あれば終わるし、終わったらすぐに次のゲームが始まるのでテンポよく遊べる。


そして、1ゲーム終わるたびに、このゲームの世界の断片情報が、少しづつわかってくる。

ゲーム自体はランダム要素が強いのだが、ストーリーがあるのだ。


いや、ストーリーというよりも、一時期流行した言い回しだと「ナラティブ」ってやつだな。

語るのではなく、感じさせる世界観。




先にランダム要素が強いと書いたが、運ゲーという意味ではない。

毎回配役がランダムに決まる、というだけで、その後の心理戦は妥協がないのだ。


コンピューター相手なのに、心理戦がリアルに感じられる。

というのも、インタビュー記事などを読むと、内部に膨大なパラメーターを計算しているらしいのだ。


キャラクター間の仲の良さがあり、それとは別に誰がグノーシア(人狼に相当)か、という疑念の値がある。

また、議論で発言しすぎれば目立ち、黙り過ぎても目立つ。


仲が悪ければそれだけで疑われるし、グノーシアだと思われれば当然疑われるし、目立っても疑われる。


ここに、キャラクターごとの強烈な個性が加わる。

嘘を見抜くのがうまい人、嘘をつくのがうまい人、人を扇動するのがうまい人、理性的に導くのがうまい人。


人間相手の人狼だと、人間関係がこんがらがってくることもあるだろう。

グノーシアでは、だれがどんなことを言った、という簡単なログが記録され、いつでも参照できる。

(詳細な言葉も、直近のものは記録されている)


これらを勘案し、考え始めると…

コンピューターのプログラムにすぎない「キャラクター」が、本当に心を持っているかのように活き活きしてくる。

心理戦がリアルに感じられる。



でも、先に書いたように、相手はコンピューターだ。

自分のペースで話を進められる。

じっくり悩んでもいいし、直感で決めてもいい。


先に書いたように、テンポよくゲームが進む。

人間相手の面倒くささは一切ない。




作った作者がゲームを楽しめる、というのが開発の指針としてあったそうだ。

だから、どのようにゲームが進むかは、作者すら想像つかない。


作者すら考えないような神がかった展開になって驚くこともあった、とインタビューで答えている。


ランダムに話を進めながらも整合性を保てるように、シナリオを管理するプログラムも分散処理で、100以上のロジックが動いているという。


僕もゲーム業界にいた人間として、よくぞそんな方法でバグも出さず…

と思ってしまうが、バグは出てもいいんだそうだ。


全く支離滅裂な話の展開になっても、そういうものだ、という世界観が設定してあるらしい。

まだそんなにやり込んでいないから、それがどういうことかわからないけど。




まだあまり遊んでいないが、子供たちが遊んでいるのは少し見ている。

これだけでも非常に楽しい作品だ。


以前も書いたが、僕はゲームレビューを書くときは、人に勧められることを基準にしている。

だから、普通は2時間程度あそんだだけではレビューを書かないのだが、もう勧めたくてしょうがないのだ。


この作品は間違いなくお勧め。



▲目次へ ⇒この記事のURL

関連ページ

続・グノーシア【日記 22/01/11】

別年同日の日記

01年 11/24

02年 オムライスとカレー

07年 保育園イベントいろいろ

10年 ディズニーランド公式ホテル

11年 しつこくデフラグ話

13年 ピエール・ベジェの命日(1999)

16年 マジカル頭脳パワー!!


申し訳ありませんが、現在意見投稿をできない状態にしています

ネットワークHUB故障  2021-10-10 11:16:29  コンピュータ

▲目次へ ⇒この記事のURL

昨夜のこと。

子どもたちが、「ネットに繋がらなくなった」と報告してきた。


自分でも確かめてみると、WiFi に接続できない。


こういうことは、2ヶ月に一度程度の頻度で起きる。

大抵はネットワークの上流で何かあったときで、5分も経てば自然に回復する。


ただ、なにか違う気がした。

いつもなら、「インターネットに接続できない」であり、「WiFiに接続できない」ではないのだ。


ここで、我が家のネットワーク構成なのだが、WiFi ステーションが2基ある。

1基では家の中すべてをカバーしきれないためだ。

居間と仕事部屋においてあり、これで家全体をカバーできる。


このときは居間にいて、自動的に電波の強い居間のステーションが選ばれていたのだけど、あえて仕事場のステーションに繋いでみる。

普通に繋がった。仕事場のステーションは外部につながるルーターも兼ねており、接続状況を確認できる。

問題なく外部に接続していた。接続できないのは、上流の問題ではなく、家の中の問題だ。


居間のステーションをリセットしてみるも、回復しない。

WiFi の電波は出ていて接続を試みるも、「DHCPに接続できない」と言われるのだ。


あらためて WiFi ステーションを確認するが、インジケーター LED の点灯が少ない気がする。

もっとも、普段それほど気にしていないので、普通の点灯状態を覚えていない。


まぁ、おそらくは WiFi ステーションが家のネットワークから切り離されている。

DHCP は家の中に1台しかないので、ネットワークから切り離されて見えなくなっているのだろう。


困ったな、ステーション壊れたかな…と思いつつ、ネットワーク全体の確認を行うため仕事部屋に向かう。

家の中の機器のほとんどは、仕事場に集約してあるから。


で、ひと目見た瞬間に原因がわかった。

家のネットワークの分岐の中心である HUB が、電源ランプが点滅し、すべての接続ランプが消えた状態だった。故障したのは HUB らしい。


先に書いたように、外部に接続するルーターを兼用している WiFi ステーションは、当然 HUB を経由せず外に接続できる。

そのため、仕事部屋の WiFi に接続すれば問題なくインターネットに接続できていたわけだ。


このステーションは、4ポートしかないが、HUB 機能を内蔵している。

そのため、外部公開しているサーバーも、このステーションに直接接続してある。

なので、外部公開サーバーの稼働はつづいていた、はず。




壊れた HUB は8ポートだったが、実際には使われていないケーブルも繋がっていた。

家の中の主要な部屋に LAN ポートを用意しているが、現在は WiFi を使うことが増えたため使っていない部屋が多いのだ。


現在使っていない 5ポートの HUB があったので、本当に必要な線を厳選して繋ぐことにした。

…以前は線に接続先の部屋を書いた紙をつけていたはずなのだが、いつの間にかなくなっている。適当に繋いで、接続ランプがつかないやつは使っていない部屋だろう。


刺しては「あたり」「はずれ」と判定する、黒ひげ危機一発のような状況。

幸い、5ポートで丁度足りた。


とはいえ、余裕がないのも困りそうなので、早速8ポートの HUB を Amazon に注文。

以前は 8ポートは高かったのだけど、いますごく安くなっているのね。


十分な機能のものが、1700円だった。

壊れたものは…多分10年以上使っていたと思うのだけど、1万円以上した気がする。


▲目次へ ⇒この記事のURL

別年同日の日記

04年 大型の勢力

16年 CentOS 7 上の ndjbdns の落とし穴

17年 オーラ写真倶楽部


申し訳ありませんが、現在意見投稿をできない状態にしています

コンピューターと気象予測  2021-10-08 17:24:01  コンピュータ

▲目次へ ⇒この記事のURL

ここのところ仕事が忙しくて、日記を書く暇もネタもなかった。

ネタも、というのは時間があれば仕事してたからね。インプット無くしてアウトプット無し。


自営業にとって仕事が忙しいというのはありがたい話なのだけど、忙しい理由の8割くらいは、先月コロナ罹患で3週間ほど休んだからだろう。

スケジュールに無理が生じて、急いでプログラムを作らなくてはならなかったのだ。



あと、仕事を手伝っている会社では、コロナ禍の状況の中でも業績が伸びている。

ありがたいことだが、ベンチャー企業で少人数なのでプログラマーの手が足りない。


求職中の腕の立つ人がいたら、こちらのページの右上の「採用情報」から詳細が見られるので、是非。

(僕はお手伝いしている外部の人、という位置づけなので、採用に関して口を出す権利はないが、一緒に働くことになったら仲良くしてください。)




ネタもない、と書いたが、日記に書こうと思って時期を逃したネタを…



数日前に、真鍋さんのノーベル賞受賞、という話がニュースをにぎわした。

日本人が受賞、と報じられたのだが、日本生まれだが、60年以上前に渡米し、現在米国籍なのだからアメリカ人だろう。


まぁ、そこはどうでもいい話で、興味を持ったのはその授賞理由。

コンピューターによる数値演算で気象を再現する手法を編み出したことだ。


今では当たり前の技法だし、真鍋氏が最初に考案した方法よりももっと精度が高まっている。

でも、最初に考案した、というのはすごいことだ。



で、ここからは日記ネタにしようとした理由。

真鍋さんは渡米してから師事した方に言われて気象予測モデルの構築を始めたようなのだけど、これが僕が過去に書いた ENIAC の記事の話とつながるのだ。


ENIAC は弾道計算のために作られた、とされる。

実際、作成の際には陸軍が予算を出していて、その理由は弾道計算ができるからだ。


でも、予算がつく前に計算機が欲しい人がいて、設計が行われて、作成する段階でスポンサーを探したのだ。

その設計の理由は「気象予測には膨大な計算が必要だから」だった。



専門ではないので正確な時期を知らないのだけど、20世紀の前半のどこかで、「完全なパラメーターがわかれば、気象は完全に計算できる」という仮説が生まれたそうなのだ。


20世紀に入っても、自然は人智の及ばざるもので、天気もその一部だと考えられていた。

それを、完全に計算できるというのだ。それまでの価値観を打ち壊すような仮説だった。


これは当時の学者にとってなかなか興味をそそる話題だったようで、多くの人が研究に乗り出している。

(こういう研究って、時代の流行もあるのだ)


ENIAC はその過程で必要とされ、設計されたものだった。

その設計者の仮説では、ENIAC くらいの能力があれば気象予測ができるはずだったのだ。


でも、ENIAC ができて気象予測ができるようになった、とは聞かない。

その時の仮説が間違っていたのだろう。

または、ENIAC では能力が足りなかったのかもしれない。



しかし、ENIAC は電子計算機の時代の扉を開けた。

その後、計算機が強力になり、その計算力を武器に気象予測のモデルづくりに挑む学者はたくさんいて、真鍋さんはその中でも見事に「実用的になる」モデルを組み立てた、ということなのだろう。




真鍋さん最初のモデルは、単純化しすぎて正しくないと分かっていながら、当時のコンピューター性能で計算できる妥当なモデルだったようだ。


その後、計算機の高速化とともに改良されたし、こうしたモデルを動かすための「地球シミュレータ」なんてものまで設計された。


(地球シミュレータは、その後も代変わりしているが、単純な計算能力ではすでにそれほどすごいコンピューターではない。

 しかし、気象予測のようなものに必要な複雑系を扱えるような独自設計になっており、気象予測や数値風洞と呼ばれるようなプログラムの実行では、まだ高い性能を誇る)



というわけで、今年のノーベル物理学賞は、自分のページで取り上げても良いネタだな…

と思いつつ、すっかり時期を逸してしまったので、この程度の簡単な説明にとどめておく。



▲目次へ ⇒この記事のURL

別年同日の日記

06年 お月様

13年 デジタルミレニアム著作権法成立の日

14年 鎌倉オクトーバーフェスト 2014

15年 ヘイリー兄弟の誕生日(1949)


申し訳ありませんが、現在意見投稿をできない状態にしています

SSL 証明書  2021-08-29 09:59:14  コンピュータ

▲目次へ ⇒この記事のURL

恥ずかしながら、今朝未明の3時ごろから先ほど、9時40分ごろまで、このWEBサイトにアクセスできなくなっていた。


原因は、SSL証明書の失効。

Let's Encrypt で取得し、自動更新する設定にしていたのだが、今年の上半期の終了、5月末日を持って古いプロトコルが廃止されたらしい。


3年前には、新プロトコルも、対応するツールも公開されていたのに、気づいていなかった。

6月1日の直前にも、メールで「旧 API廃止」と警告されていたのに、気づいていなかった。

さらにその後も「証明書更新してないよ」という警告が来ていたのに、気づいていなかった。


どんだけボンクラなんだ、って話だけど、仕事ならともかく、趣味でやっているサイトなのでそこらへんはいい加減だ。

申し訳ない。

(SSL は基本技術過ぎて空気のようなもので、無くなって初めてその存在に気付くのだ)



で、最後に更新していたのが5月29日。

Let's Encrypt で発行される証明書は期限が3ヵ月なので、今朝失効したというわけ。




失効すると1から取得しなおさないといけないのだけど、もう何年も取得なんてしていなかったので、やり方忘れていた…


9時前に失効に気づき、慌てて作業しようとするも、作業手順すら忘れていた。

というか、どのマシンで証明書の自動取得を行っていたかすら忘れていて、違うマシンの中でコマンドを探し始める始末。

(WEB サーバー証明書だから、WEB サーバーで処理しているに決まっているのに)


ネットで情報探しながら作業して、およそ1時間。やっと再取得できた。



いろいろとエラーを出しながら、そのエラーを解消していく、ということの連続で、最後のエラーが「API v1 にアクセスできないよ」というメッセージだった。

ここでやっと根本原因に気づいたのだった。



3時間後の追記


ついで(?)なので、古くなっていた SSL 関連の設定を見直してみた。


もう5年も前にチェックしていたSSL LABSでチェックを行ってみた。


一応、その後も時々はチェックしていたのよ。ずっと A+ だった。

でも、久しぶりにやったら B だった。


TLSv1.0 と v1.1 のプロトコルは、「脆弱性がある」ということで、昨年頭に各ブラウザ一斉に使用しない設定に替わったらしい。

それをうけて、これらのプロトコルを許可しているサイトは、B ランク以下にするようにした、という説明があった。



なるほど、そうなのか。気づいていなかったということは、最後にチェックしたのは1年半以上前だということだ。


早速、これらのプロトコルを使えないように設定する。

ついでに、TLSv1.3 をサポートするように、新しい openssl と nginx を導入する。


これで評価が A+ に戻った。


古いプロトコルのサポートをやめた影響で、IE11 以外の「古いIE」を使っている人は、アクセスできなくなった。

あと、Android 4.3 以前(Chrome ではなく、Android Browserを使用する機種)や、Mac Safari の 6.0 (8年前のバージョン)以前もアクセスできなくなっている。


ここを見られなくなった方、ごめんなさい。(と、ここで謝っても読めないわけだが)



というか、IE11 は結構古い(リリースは8年前)のに、ちゃんと TLSv1.2 には対応しているのだな。

そのつもりでレポートを読むと、以前苦労して対応した、Chrome 49 と Firefox 47 (どちらも5年前のバージョン)でも、まだアクセスできるようだ。


IE11 はまだ使っている人いそうだな…

(僕も仕事上使うことがある。動作チェックだけど)


Chrome や Firefox は自動更新なので、こんな古いバージョンを使っている人はいないと思うのだけど、ちゃんと見られますよ、ということで。


▲目次へ ⇒この記事のURL

別年同日の日記

13年 次女発熱

16年 マイケル・ジャクソン 誕生日(1958)

19年 Nintendo DSi


申し訳ありませんが、現在意見投稿をできない状態にしています

IOCCC  2021-07-24 18:51:59  コンピュータ

▲目次へ ⇒この記事のURL

オリンピックが始まったが、IOC ではなくて、IOCCC の話。


IOC は International Orimpic Comittiee (国際オリンピック委員会)の意味だけど、

IOCCC は the International Obfuscated C Code Contest(国際難読Cコードコンテスト)だ。




IOCCC の話は、昔の日記でちょろっと出したことがある。


「難読」ということになっているけど、この意味は多様だ。

ソースを見ても動作が想像できない、程度に考えておくとよいと思う。


だから、数学的に高度なことを行っていて想像つかないようなものもあれば、C言語の仕様を悪用しているものや、単に読む人に対する「いたずら」をしているものもある。


そしてもちろん、読めなければいいというだけではない。近年は「驚くような動作」が求められるようになっている。



昔、興味を持って入選作のプログラムを読もうとしたことがあったのだけど… いや、全く歯が立たなかった。

特に古いプログラムは、現代の環境では動かないものも多く、動作させながら理解することも難しい。



ところが数日前に、過去に入賞した全作品の解説を、日本語で行っているページが今年に入ってから作られているのを知った。

現代の環境で動かすためのパッチなども示されている。


これがまた、面白い。

解説を読んで感心したり、面白そうなプログラムは自分でも動作させてみたりしながら、何日もかけてゆっくり楽しんでいる。




いったい誰がこんなページを、と思って確認したら、近年の IOCCC で常連の日本人だった。

しかも、その受賞作のいくつかは、IOCCC とは無関係に、その動作のすごさがネットで話題になっていたりしていて、見たことがあった。



ところで、第1回大会は 1984年に開かれている

この時の大賞作品について少し話をしよう。


C言語では、プログラムの制作者は必ず「main」と名付けられたプログラムを作り、それが最初に呼びだされることになっている。

しかし、対象作品には main がない。それどころか、プログラムが1行も書かれていない。


代わりに、main という名前のデータを定義している。このデータも、意味不明の数値が並んでいるだけだ。



じつは、C言語では「名前」にプログラムとデータの区別はない。

だから、main という名前のデータがあれば、言語のシステムはそれがプログラムだと思って最初に呼びだしてしまう。


ところが、内容は数値データだ。実はこの数値データは、当時 UNIX の世界では一般的だったコンピューター、PDP-11 の機械語命令コードなのだ。



そんなわけで、このプログラムは大賞をとってはいるが、PDP-11 がないと動かない。

先に僕が「現代の環境は動かない作品も多い」と書いたが、要求されるマシン環境すら限定されるのだ。



さて、話を戻して、この解説記事を書いてくださっている人の話。

IOCCC の常連と書いたが、2015 年の作品で「1984 年の作品を動かすための PDP-11 エミュレータ」を作っている。


これにより、PDP-11 がないと動かないはずの作品ですら、動作させることに成功している。

とにかくこのコンテストが好きで、過去の作品の動作も見てみたい、という愛にあふれている。


愛のある人が解説をしているのだから、その面白さは保証されていると言ってよいだろう。




最後に自分の想い出語り。


このコンテストの「存在」を知ったのはずいぶん昔…年齢がばれるが、大学生の時に友人から聞いたもので、1992年ごろだったと思う。


その時はまだ WEB も普及していなかったし、話に聞いただけで作品を直接見たわけではない。

でも、 2["abc"] と書くことで c を取り出せるとか、配列に機械語を入れて呼び出すことができるとか、C言語の「低レベルな」仕様の話を聞いて、すごく面白いと思ったものだ。


(僕は当時、PDP-11 を参考に作ったという MC68000 CPU のアセンブラは理解できていて、C言語も初心者ではあったが理解していた。そのため、 [ ] が配列を意味するのではなくアドレス演算にすぎない、という話は素直に理解できたのだ)



当時の理解としては、とにかく仕様の穴を突くようなプログラムテクニックを競う、というようなものだと思っていた。

いや、実際初期の作品はそういうものも多い。


でも、制約の中で複雑な動作をつくる、という側面も大きい。

今だと、C言語以外でも文字数の制約の中でプログラムを作るようなコンテストは行われているのだけど、そういうコンテストのさきがけの一つともいえる。


となると、そこには単に「難読」というのを超えた、素晴らしい工夫がたくさん入っているのだ。


日本語解説ページで取り上げられている作品は非常に多く、まだ全部は読めていないが、そうした工夫を見るのは非常に楽しい。



とりあえず、コンテストの比較的初期の中から気に入った作品を1つ上げておこう。


[[1990/westley]]


この作品は、プログラムが「往復書簡」のように読めるように作られている。

もちろん、C言語のプログラムとしての制約があるため、英語そのものではない。でも、「英語っぽく」読めるように工夫されているのだ。


往復書簡の登場人物は、 char*lie と char lotte 。チャーリーとシャルロット、なのだけど、C言語の char 型の変数定義になっている。

英語そのものではないが、英語っぽく読める、というのはそういうこと。


で、この二人がラブレターを送りあっているのだけど、途中から仲たがいして、破局に至るまでがつづられている。


これはプログラムなので、コンパイルして実行できるのだけど、花占いのプログラムになっている。

「好き」「嫌い」って交互に表示するプログラムなのね。


で、これを作った作者のコメントによれば「char*lie と char lotte は非互換」とのこと。

(C言語わかる人ならわかるね)


つまり、英語のラブレターとして読めて、C言語のプログラムとしても読めて、実行すると恋愛占いで、その登場人物の相性が悪いのは最初からわかってるだろ、と、4つも意味を重ね合わせている。



超絶技巧。


これは、ソースコードが英語だ、というわかりやすさがあったので紹介したけど、他にも舌を巻くような作品ばかり。

行単位でランダムにソートしても、必ず動くプログラムになる作品、なんていうのもあったな。


プログラマーなら読んでみると楽しめると思う。



▲目次へ ⇒この記事のURL

別年同日の日記

15年 マイコプラズマ肺炎

17年 テレワーク・デイ

17年 スプラトゥーン2初感


申し訳ありませんが、現在意見投稿をできない状態にしています

続・FFMPEG  2021-07-18 12:27:59  コンピュータ

▲目次へ ⇒この記事のURL

最近 NAS の話ばかりで恐縮だが、また昨日の続きだ。


文章を書くというのは現状の整理に役立つ。

昨日の日記を書いているときは、QNAP サポートとのやり取りを公開・記録して「仕様ということで、AVCHD を見るのは諦めるしかありません」というまとめにする予定だった。


でも、それまでに集めたデータを、人に伝えるために整理しているうちに「あれ? これ、なんとかなるんじゃないの?」と思うようになった。


それが最後に書いた部分で、含みをもたせた終わり方になった。

この時点では自分では試しておらず、可能も不可能も言い切れる段階にないと思ったためだ。




現時点で続きを書いているというのは、もちろん進展があったためだ。

完全ではないが、QNAP から AVCHD の動画を見られるようになった。


ただし、Web アプリの QuMagie からの再生だけ、うまくいっていない。

写真閲覧の機能が充実しているだけに、この点が残念だ。


具体的に言えば、AVCHD から mp4 へのトランスコードは可能になるのだが、QuMagie だけは元ファイルを参照しようとしてしまう。

FileStation や VideoStation では、トランスコード済みのファイルを参照するように設定する項目があるのだが、QuMagie にそのような設定が見当たらないのだ。


(Android アプリ版の QuMagie では設定が行えるため、動画の再生に支障はない)



そんなわけで、完全ではないがかなりの状況改善だと思う。




では、設定方法を記そう。


前提条件として、NAS に ssh ログインして管理者権限で作業を行う必要がある。

管理者権限での ssh 作業というのは、「NAS を壊すかもしれない行為」だ。

意味が理解できない人はやるべきではない。


ただ、Linux などに慣れている人であればさして難しい作業ではない。

251D の、日記執筆時点での環境を前提に話を書くが、多少違っても対応できるように、作業の「意味」も記しておく。



まず、NAS を ssh ログイン可能な状態にしよう。

コントロールパネル → ネットワークとファイルサービス → Telnet / SSH で、SSH 接続を許可する。

このとき、「アクセス許可の編集」で、接続できるユーザーも設定しておこう。


ssh クライアントは自由に選んでくれ。…この言葉の意味がわからない人は、NAS を壊す危険があるので諦めよう。


ssh ログイン可能なことを確認したら、ひとまずこの作業は終わり。



つづいて、AppCenter から FFmpeg をインストールする。

普通、AppCenter には QNAP 純正のアプリしか表示されないが、AppCenter には「サードパーティのアプリ」をインストールさせるための機能もある。


海外には QNAP Club という大きな QNAP ユーザーのコミュニティがあり、そこでは、AppCenter に設定することで直接インストールできる形式のアプリをたくさん公開している。

これを AppCenter に設定しよう。


AppCenter を開き、右上の歯車アイコンをクリックし、「設定」パネルを開く。

「アプリリポジトリ」のタブを開き、「追加」ボタンを押す。


すると、リポジトリ(アプリ置き場)の URL などを尋ねられる。

名前は QNAP Club 、URL は https://www.qnapclub.eu/en/repo.xml を登録しよう。

ユーザー名などは不要だ。


これで、AppCenter の左端に「QNAP Club」というアイコンが表示されるようになる。


そのアイコンを選ぶと、QNAP Club の「マイアプリ」を表示した状態になる。

過去にインストールしたアプリの一覧だが、当然なにもない。


左端から2番めの縦の帯(言い方が難しいな)の中に「マイアプリ」と「すべてのアプリ」の切り替えがあるので、全てのアプリを表示する。


大量のアプリが表示されるので、上にある虫眼鏡アイコンをクリックし、 ffmpeg を検索しよう。

日記執筆時点では、バージョン 4.4.0 だった。


後はインストールするだけだ。

この ffmpeg は ac3 にも H.265 にも対応しているので、AVCHD だけでなく、最近のスマホの動画形式も見ることができるようになる。

(公式には CAYIN の有料コーデックを買わなくては H.265 対応にならない、ということになっているのだが)




さて、ffmpeg が入っても、QNAP の OS はこれを使ってくれない。

現在入っている ffmpeg ではなくこちらを使うように…OS を騙す設定をしよう。


ここからは、ssh での作業だ。


まず、AppCenter でインストールされたパッケージは、各種共有ディレクトリと同じ階層の隠しディレクトリに入る。

ただ、この共有ディレクトリの実態は、環境により異なるらしい。


環境によりディレクトリが違うというのは、面倒な手間になる。

そこで、QNAP では、ソフトリンクによってこの違いを隠蔽する。


/share/Public がソフトリンクになっていて、ここにアクセスすれば共有ディレクトリにアクセスできる。

まずは、このディレクトリのソフトリンクがどうなっているか確認しよう。

(ls -l で確認できる)


251D の場合、


ls -l /share/Public

lrwxrwxrwx 1 admin administrators 21 2021-07-11 10:46 /share/Public -> CACHEDEV1_DATA/Public/


という結果が得られた。/share/CACHEDEV1_DATA/Public が共有ディレクトリの実態だ。

このディレクトリと同じ階層の隠しディレクトリ、.qpkg の下が、パッケージからインストールされたアプリが入るディレクトリだ。


つまりは


/share/CACHEDEV1_DATA/.qpkg


の下で作業を行う必要がある。


ディレクトリ内には、少なくとも、先ほど入れた ffmpeg と、トランスコードなどを行うプログラムである MultimediaConsole が入っていると思う。

251D ユーザーでトランスコードを使いたいなら必須とされる、MediaSignPlayer も入っているだろう。


(少し以前の機種のユーザーであれば MediaSignPlayer ではなく、CodexPack が必須となるようだ)


さて、MultimediaConsole と MediaSignPlayer の下には、それぞれ別の ffmpeg が入っている。

どちらも、ac3 や H.265 のサポートを外してあるものだ。

(昨日も書いたが、ライセンスの問題があったのだろう)


具体的なファイル位置は、以下の通りだ。


ffmpeg/ffmpeg

MultimediaConsole/medialiblary/bin/ffmpeg

MediaSignPlayer/CodexPackExt/static/bin/ffmpeg


ffmpeg/ffmpeg で、それ以外の ffmpeg を上書きする。


まぁ、上書きと言っても実際には、古いものは ffmpeg.bak のような名前にリネームしておき、新しいものをソフトリンクしておくのが良いと思う。


なお、普通に ffmpeg を起動するときは /usr/bin/ffmpeg が動作するのだが、これは MultimediaConsole の ffmpeg へのソフトリンクだ。



まとめると、251D の場合は、ssh 上で行うべきは次の作業。

(ここまでに書いた意味を理解したうえで実行すること。最初に警告した通り、意味が分かっていないと NAS を壊す可能性がある)


cd /share/CACHEDEV1_DATA/.qpkg/

mv MultimediaConsole/medialiblary/bin/ffmpeg MultimediaConsole/medialiblary/bin/ffmpeg.bak

mv MediaSignPlayer/CodexPackExt/static/bin/ffmpeg MediaSignPlayer/CodexPackExt/static/bin/ffmpeg.bak

ln -s ffmpeg/ffmpeg MultimediaConsole/medialiblary/bin/ffmpeg

ln -s ffmpeg/ffmpeg MediaSignPlayer/CodexPackExt/static/bin/ffmpeg


なぜ2つの ffmpeg を持っているのかは不明だが、現在は MediaSignPlayer をインストールしないとトランスコードができないので、MultimediaConsole のものは「歴史的経緯」で残っているだけかもしれない。




以上の作業で、AVCHD ファイル (拡張子 MTS)のトランスコードが可能になる。


一応オンザフライ(再生するその場で変換を行う)のトランスコードも可能なのだけど、処理速度が遅くて実用にならない。

あらかじめトランスコードを行う設定をしよう。


なお、「あらかじめ」のトランスコードの場合、ファイルが生成されるので保存容量を使う。

元の品質と処理後の品質にもよると思うが、僕は「内容が確認できれば良い」と割り切って、360p のデータを生成することにした。

(デフォルトもこの値なので、お勧めなのだろう)



我が家の場合、元はハイビジョンの 1920 x 1080i。

これを 640 x 360p に変換するので、この時点でデータ量は 2/9 になる。


実際には圧縮の効きやすさとか、動画ごとの特性もあるのだろうと思うが、データは 1/5 ~ 1/10 程度のファイルサイズになるようだ。

このくらいなら利便性の代償として、使っても良い程度の容量に思える。


MultimediaConsole アプリの「トランスコーディング」設定を行うだけで、特に難しいことは無い。

これは標準の機能なので詳しくは解説しない。



最後に、動画を再生する際に、トランスコード済みのファイルを参照するように設定する必要がある。

ある程度トランスコードが終わってから、ファイルが生成された動画を使って確認するといいだろう。


・アプリの場合、動画再生しようとした時点で、品質を聞いてくると思う。

 360p を選べばよい。「この設定を記憶する」をチェックしておけば、今後は常にその品質を使ってくれる。


・QTS 上の FileStation (つまり Web アプリ)の場合、MediaViewer というウィンドウが開く。

 再生できないと言われるが、これは元ファイルを参照しているため。

 右下の、フィルムと歯車を組み合わせたアイコン(ビデオ設定)を開き、「オンラインストリーム再生」の項目を「360p」にすると再生される。

 設定は記憶されるので、以降はどのファイルを開いてもすぐに再生されるようになる。


・VideoStation の場合も同様に設定する。というか、FileStation で開く「MediaViewer」の実態は VideoStation の再生ウィンドウのようで、上の設定はこちらでも活きているはず。


・PhotoStation では、動画を見ようとすると再生品質を聞いてくる。

 360p を選べばよいのだけど、記憶させる設定はなく、毎回聞かれる。


・CAYIN MediaSignPlayer では、元のファイルとトランスコード済みファイルが並んで表示される。

 トランスコード済みを指定すれば見ることができる。

 (しかし、CAYIN はトランスコードに必要だから入れているだけで、全体に使いやすくはない。

  わざわざ使う必要はないだろう)



そして、最後だ。

Web アプリ版の QuMagie 。最初に書いた通り、設定の方法がわからず、動画が見られない。


AVCHD ではない、普通にみられる動画で実験してみると、QuMagie で動画を見た場合にも、右下に歯車アイコンが表示され、品質を設定できる。


ただ、この時設定した品質を記憶してくれないのだ。

そのため、必ず「元のファイル」を表示した後で「トランスコード済みのファイル」を再生するように指定する必要がある。


この時点で、AVCHD は元ファイル表示ができずに終わりなのだ。



非常に残念だが、ビデオを気軽に見たい理由は「家族に見せるため」だ。

僕が見たいのであれば、Windows 上でファイルを開けばよい。


なので、目的はほぼ達成されたと言ってよいだろう。

FFmpeg を公開している、QNAP Club に感謝。



翌日追記

Amazon Fire TV Stick 用の Qmedia も試したが、動画は見られなかった。

トランスコード済み動画を使用する機能がなく、360p を指定してもオンザフライになってしまう。

このため、使い物にならないくらい遅い。


Fire TV Stick だからテレビが前提で、圧縮しない元データで見るという前提のようだ。


もっとも、この Qmedia というソフト、Fire TV 専用であまり使いやすくなかった。

(家族の想い出ベースで…写真と動画を一緒に見たいのだが、Qmedia では写真と動画は全く違うもの、という扱いだった)


▲目次へ ⇒この記事のURL

関連ページ

FFMPEG【日記 21/07/17】

別年同日の日記

07年 電車のパン

13年 ハングアウト

16年 山登り

18年 年棒制


申し訳ありませんが、現在意見投稿をできない状態にしています

FFMPEG  2021-07-17 18:25:39  コンピュータ

▲目次へ ⇒この記事のURL

QNAP 251Dのその後。


前回書いたが、AVCHD で撮影したビデオを見ることが出来ない。

QNAP に「どうにかして」とお便りを送ったところ、数度のやり取りの後「現在のところ、仕様」という予想通りの答えとなった。


でも、サポート担当してくださった方はこの問題を知らなかったようで、色々と調べてくださった。


その中で、以前は(僕が前の NAS である 220 を購入した頃には)フリーウェアを使って変換していたが、その後フリーウェアの開発終了にともない、サポートできなくなった、という情報を得た。




QNAP は、アプリをダウンロードすることで機能を拡張できる。

機種によって提供されているアプリが多少違うのだが、少し前の機種では CodexPack というものがあったらしい。

これは FFmpeg の拡張コーデックで、入れると対応できるビデオ形式が増えたそうだ。

(アプリを増やせばメモリを食うようになるため、必要な人だけ入れれば良い、という配慮)


つまり、内部的にはフリーウェアである FFmpeg を使用していた、ということ。

FFmpeg は、非常に多くのビデオ・音声形式を相互変換したり、編集したりできるフリーソフトだ。


つまり AVCHD が見られた、「以前の」フリーウェアは使わなくなったが、その後は FFmpeg を使っていた、ということになる。


はて。FFmpeg なら、AVCHD にも対応できるはずなのだが。




しかし、今は CodexPack は提供されていない。

各種情報を総合して考えると、いまでも FFmpeg は使っているのだが、CAYIN MediaSignPlayer というサードパーティアプリの一部として提供されている。

そして、拡張コーデックは無償提供ではなく、別売りになっている。


ただ、この拡張コーデックを買ったとしても、AVCHD には対応できない。

CAYIN の WEB ページを見ると、ページ下部に FAQ があり、そこに「現在のところ AC3 には対応していない」と書かれていた。


QNAP でAVCHD が見られない最大の理由は、AVCHD で使用されている音声フォーマットである AC3 に対応しないためだ。


FFmpeg が対応しているのに、なぜ対応しないのだろう。




QNAP には ssh ログインの機能もある。

NAS の OS の基幹部分である Linux を見せてしまう、ということだ。

NAS は安定性が第一なので余りいじりたくはないのだけど、入ってみた。


ffmpeg コマンドを実行すると、たしかに入っている。

そして、usage メッセージには、ffmpegのコンパイルオプションが示される。


ここに、 --disable-decoder=ac3 と書かれていた。「ac3 は使えないようにする」という指示だ。

つまり、CAYIN が対応していないというだけでなく、その内部で使われている FFmpeg も、わざわざ AC-3 を使えない状態にしてある。


バージョンは、3.3.6 、結構古い。どうやら 2017 年のバージョンらしい。

Debian の一部としてコンパイルされたもの、らしい。




…他にも色々調べ物をしたが、見えてきたのはこういうことだ。


2011 年頃、FFmpeg プロジェクト内で管理方針をめぐる対立があり、分裂があった

FFmpeg と機能的には同じだが、管理方針の違う libav というプロジェクトが興ったのだ。


当初は両者活発に活動していた。管理方針で対立はあったが、機能面では同じものを志している。

お互いに成果を取り入れつつ、それぞれ活動していたようだ。


これを応援するように、いくつかの Linux ディストリビューションでは、libav を採用する。

Debian も libav 派だった。


しかし、やがて libav は失速する。一部が飛び出して新プロジェクトを作ったとはいえ、多くの開発者は FFmepg に残っているのだ。

新機能は主に FFmepg で実装され、libav はバグ修正すらなかなか行われない状態になる。


2015 年頃、FFmpeg のプロジェクトリーダーが辞任し、交代となった。

トップが交代するということは、管理方針にも影響を与える。

このとき、引退するリーダーは「プロジェクトが分裂しているのは望まない。戻ってきてほしい」とlibav の開発者にメッセージを出した


これがきっかけで、libav は2016年にはその活動を事実上停止した。

(一応、その後も 2018年まではリリースを続けているのだけど)


どうも、QNAP が古い機種で使っていて、開発終了になったライブラリというのは libav のようだ。

Debian なども、このときに libav から FFmepg に再変更している。


QNAP の内部の Linux が、どのディストリビューションをベースとしているかはよくわからない。

しかし、やはり同じように libav から FFmpeg に戻したのだろう。


ただ、これだけでは AC-3 非対応の理由にはならない。




AC-3 は、ドルビー研究所が考案した音声コーデックだ。

そのため、ドルビー研究所が特許を持っていて、使用するには特許料を払う必要があった。


「あった」という過去形で、2017 年には特許が失効している。


先に書いたが、CAYIN が内部に抱えている FFmpeg は 2017 年のものだ。

推察するに、CAYIN の開発を行っていた頃はまだ特許が継続していて、特許料の関係で AC-3 はサポートしないことにしたのだろう。


その後特許は失効したわけだが、「サポートしない」つもりで作成したソフトを、今からサポートするように変更するのもリスクが伴う。

そもそも、内部の FFmepg のバージョンがずいぶん古いのだ。これも、バージョンを変えたら、その上で動く CAYIN が正しく動作するのか、全チェックを行うのが大変だからだろう。


QNAP が CAYIN と提携したのは、2020 年…去年のことなので、今後どうなるのかはよくわからない。


翌日追記

CAYIN の内部 FFmpeg が 2017 年のもの、と書きましたが、勘違いでした。

QNAP は標準で内部に FFmpeg を2つ持っていて、QNAP が入れた(使っていない?)FFmpeg が 2017年のもの、CAYIN は 2020 年のバージョンでした。


しかし、AC-3 をサポートしていないのは同じです。

どうも「AC-3 自体の特許は失効したが、関連特許が残っているため念のためサポートを見合わせている」ということのようです。


追記終わり。




ということは、だ。

おそらく、内部の FFmpeg を、しれっと AC-3 対応に変えてしまえば、ビデオが見れるようになるのかもしれない。


AC-3 対応が目的ではないが、同様のことを試みている人がいる。


機種が違うし、このパッケージは「CodexPack」が入っていることを前提としているので、251D で動くかは不明だ。

変なことをして NAS の動作を不安定にするのも嫌なのだけど、どこかで試して見る価値はあるかもしれない。



→ 翌日試しました。AVCHD 動画も見られるようになりました。



▲目次へ ⇒この記事のURL

関連ページ

続・FFMPEG【日記 21/07/18】

別年同日の日記

02年 冷蔵庫に乾杯

14年 続・世界初のMML

15年 NECの創業日(1899)

15年 エジホン探偵事務所

20年 phpSpreadsheet で小数点付き数値と見なせる文字列を入力するとおかしくなる


申し訳ありませんが、現在意見投稿をできない状態にしています

251D 使用レビュー  2021-07-04 16:54:00  コンピュータ

▲目次へ ⇒この記事のURL

QNAP の NAS TS-251D の導入だけで大変だった、という話を書いたが、ここからはやっと「本来やりたかったこと」を試した話だ。


旧機種 220 は、ARM CPU だった。これは家庭用 NAS としてはエントリーモデルだ。

この頃の「上位機種」は 251 だった。Intel CPU だ。


さて、220 の後継機種は 230 になる。そして、251 の後継機種は 251D だ。

今回、単純な後継機への乗り換えではなく、上位機種の乗り換えにもなっている。


220 と 251 は、当初同じ機能が提供されていた。ただ、251 のほうが動作が高速だった。

その後、新機能は 251 にのみ提供されたり、機能差が出来ていく。


僕が 220 を購入した最大の要因は、家族写真・ビデオの整理だった。

220 には「トランスコード」という機能があり、各種フォーマットのビデオファイルを、スマホや WEB でも見やすい mp4 に変換してくれた。


ところが、ある時の OS バージョンアップに伴い、このトランスコード機能が 251 だけの提供となった。

それまで使えていた機能が、ある日から急に使えなくなったのだ。



現時点で、230 と 251D には同じ機能が提供されている。

ただ、251D の方が「処理性能が高い」というだけだ。

(あと、251D は拡張可能だが、230 はそうではない)


しかし、以前の経験があるから、上位機種を買っておこうと思ったのだ。




ではそのトランスコード機能について書こう。

トランスコード機能は確かに使えるのだが、期待していた機能が入っていなかった。

かなり残念な結果だ。


我が家の家族ビデオの多くは AVCHD フォーマット(拡張子 MTS)で撮影されている。

220 にトランスコードが提供されていたときは、AVCHD は対応していた。


しかし、現在の 251D のトランスコードは、AVCHD は対応していない。


AVCHD は家庭用ビデオカメラでは広く普及している規格だ。

内容的にもそれほど特殊なものではなく、mp4 の一種に過ぎない。


ただ、mp4 というのは細かなパラメータが多い規格であり、ファイルの名付け規則やディレクトリの配置規則もない。

家電品としてはそこら辺が定まっていないと使いにくかろう、というので定めた程度の規格だ。


だから、それほど対応が難しい規格ではないはずだし、先に書いたように以前は対応できていた。

それなのに対応していないというのは…


じつは、220 が対応していた頃は「QNAPが」この対応プログラムを作っていた。

しかし、数多のビデオフォーマットに対応するのは大変だったようで、現在はサードパーティのプログラムを使って対応している。

(QNAP ユーザーは無料でインストールできるようになっている)


そして、このプログラムは AVCHD に対応していない。

QNAP が独自対応していた時は AVCHD に対応していたのだけど、数ではもっと多くの形式に対応できるサードパーティのライブラリは、完全な包含関係にはなかった、ということなのだろう。



とりあえず、対応してくれと QNAP に要望は出しておいたが、望み薄だと思っている。

多分そんな要望はすでに山ほど来ているだろうから。


このライブラリ、変換部分は ffmpeg にすぎないようなので、パラメータがいじれれば自分でも対応できるようなレベルの話なのだけど…



ちなみに、ファイルサーバーとして Windows からアクセスして、ファイルを直接見れば Windows のビデオ機能で再生できる。


ただ、一括管理ができず、不便というだけだ。




仕方がないのでビデオは諦める。

写真整理についてはどうか。


これについては、悪くない。


以前の 220 では、PhotoStation という WEB アプリが提供されていて、これで NAS に入っている写真を閲覧できた。

でも、この使い勝手はちょっと微妙なもの。悪くはないのだけど、Google photos に比べると使い勝手が悪い。


251D にも PhotoStation が入っていて、新機能なども追加されていたのだけど使い勝手は余り変わらなかった。

ちょっとがっかり…と思ったら、新しい写真閲覧ソフトとして、QuMagie というものが入っていた。


これが、Googe photos を強く意識した…いや、正直パクリのインターフェイス。

それがなかなか使いやすい。


AI による顔認識とか、写真に写っているものの認識とか、EXIF 情報の GPS 位置による場所の認識とかがあって、写真を自動分類してくれる。


顔認識の精度は、ちょっと微妙かもしれない。

というのは、うちの三人兄弟の幼児期の写真を区別できない場合も多かったから。


もっとも、顔だけ見ると親でも識別できないような写真ばかりだけど。

親は周りのシチュエーションで誰か区別できるのだけど、AI はそこまで出来ないので区別できないのは仕方がない。



まぁ、Google photos も有料化したとはいっても、当面の無料使用可能な容量があるので、当面は使い続けるのだけどね。




導入部分で書いていた、スナップショット機能について。

これ、すごく期待していた機能だ。


「大切なデータを守る」というのは簡単なのだけど、どうすればそれができるのか、という方法論は実は奥深い。


RAID は、ディスクの故障からファイルを守ってくれる。

でも、人間のうっかりミスで消してしまった、上書きしてしまった、などの事故からは守ってくれない。


Windows には、「シャドウコピー」という機能がある。

ある瞬間のディスクの状態を記録しておいて、いつでもそこに戻れるようにする機能だ。


ファイル1個単位でも戻せるのだけど、よく使われているのは「システムの復元ポイント」だろう。


こちらは、システムフォルダを丸ごとシャドウコピーしている。

Update などの前に自動的に作られ、その直後の再起動で失敗すると、自動的に以前の復元ポイントに戻ったりする。


同様の機能が、MacOS X でも提供されているし、Linux でも LVM の一部として提供されている。

そして、NAS のスナップショット機能も、この LVM を使用したものだ。


先に書いたように、Windows にも類似機能があり、NAS をファイル共有で見ると、Windows 上の通常のファイル操作で「以前のバージョン」に戻すことができる。


Windows の復元ポイントは 64個しか作れないが、QNAP の NAS は、256 作れる。

また、その残し方もかなり柔軟で、直近のものは1時間ごとのスナップショットを残すが、やがては1か月ごとにまとめたものを1年間残す…なんて設定もできる。


その仕組み上、こんな残し方をしていても HDD の容量はそれほど使わない、はずだ。

(まだ1週間程度しか運用していないので、1年続けたときの容量はわからない)


これは、ファイルの保全というより、うっかりミスに備える機能だと思っている。

なので、これとは別にバックアップを取る必要はあるだろう。




NAS は万全のバックアップ体制をとれるとして、個人使用のマシンのデータを NAS に効率的に送るにはどうしたらよいか。


以前は BunBackup を使っていた。Windows 用のフリーソフトだ。


でも、251D なら QNAP 公式の2つの方法が取れる。


1つは Qsync 。もう1つは NetBak Replicator 。

Qsync の方が後から作られ、高機能だというので試してみたのだが…これはなんか違うな。

僕が求めているのは NetBak Replicator の方だった。


まず Qsync の説明をしよう。

これは、MicroSoft の OneDrive とか、Google の GoogleDrive とかの、Windows 向けドライバと同様の動作を行う、QNAP の NAS 向けアプリケーションだ。


デバイスと NAS の間で、常にファイルの同期を行う。

複数台で同じ場所を同期していると、データの共有が簡単にできる。


でも、そのために保持しているパラメータは非常に多いようだ。

「同期をとる」って、案外厄介な作業だからね。


そのため、NAS のデータ置き場は、Qsync 経由でしか見られない。

勝手にファイルをいじられると、それだけで同期が破綻するためだ。


結果として、せっかく NAS にデータを集約しているのに、Windows のファイル共有などからでは、このデータにアクセスできないようになっている。


僕としては、NAS にデータを集約して、バックアップなどで万全の体制を保ちたい、というのが一番の要求だ。

複数 PC で同期をとりたいわけではないし、NAS で見られないのは魅力半減だ。


そこで、NetBak Replicator 。これは Windows の特定のディレクトリ以下のファイルを、変更があれば即座に NAS にバックアップするためのソフトだ。


一方的なバックアップであり、同期ではない。

そして、バックアップしたファイルは、ファイル共有から見ることができる。


先に書いたが、NAS にはスナップショットで過去のファイルでも取り出せるような仕組みがある。

これは、Windows からは、該当ファイルに対して「プロパティ」の「以前のバージョン」を見ることで簡単に取り出せる。


これで、個人所有の PC から NAS にデータを送り続け、バックアップする体制ができあがる。



ちなみに、スマホからは Qfile を使ってバックアップの設定ができる。

撮った写真を自動的に NAS に入れるように設定した。




まだ購入から1週間、まともに動くように(メモリを増設して)からは3日くらいしかたっていない。

なので、今のところレポートできるのはこれくらい。


でも、大体やりたい設定は終わった感じなので、後はこれらの設定がどれだけ「普段の動作を邪魔せず、スマートに」動いてくれるか、という程度だ。


ちなみに導入コストだが、当初予定していなかったメモリ増設なども含め、6万8千円ほどだ。

また6年半くらい使うとして、年間1万円程度のコストで、家族で使える 4T のストレージが入手できたことになる。


Google One ドライブなら、2T で年額1万3千円。

NAS の方がいろいろと便利な部分もあるし、悪くない買い物かな。


▲目次へ ⇒この記事のURL

関連ページ

251D 使用レビュー【日記 21/07/04】

別年同日の日記

04年 コンサート

13年 Mouse In Maze

18年 続・Unity


申し訳ありませんが、現在意見投稿をできない状態にしています

QNAP TS-251D 購入  2021-07-04 16:41:13  コンピュータ

▲目次へ ⇒この記事のURL

しばらく前に「もう一つ買ったものがあるので、後日書こうと思う」なんて予告しておいて、なかなか書けなかった。


購入したのは、新しい NAS 。QNAP TS-251D。

ある程度設定が終わったらレポートを兼ねて書こう、と思っていたが、この設定に手間取ったのだ。


今までは、同じ QNAP の TS-220 を使用していた。

6年半ほど前に購入したものだ。


その前の NAS は、6年半使ったところで壊れた。

だから、TS-220 もそろそろ買い替え時だと思うのだ。


後継機への乗り換えだから簡単にできる…つもりでいたら、思った以上にハマリポイントが多かった。なかなか日記を書けなかったのもそのためだ。


購入を検討している人のために最初に結論を書いておくと、標準のメモリ(2Gbyte)は足りなすぎる。


特に複雑なことをしない、普通の状態でも足りていない。

なぜそんな状態で売っているのか、と思うのだが、一応動作はしているので、最低限のセットで販売しているのだろう。


4Gbyte モデルも販売しているようなのでそちらを買うか、交換用の増設メモリを最初から買うのが良いと思う。


もうひとつ、乗り換えの際には、新しい NAS と一緒に新しい HDD も購入しよう。

古い機種の HDD を新しい機種に入れよう、とは考えないこと。


公式には、古い NAS から HDD を取り出して入れ替えると、今までの設定もそのまま引き継がれて簡単…ということになっているのだけど、残念な結果にしかならない。


つまり、251D を購入するなら


・本体

・HDD 2台

・増設用メモリ


を同時購入するのがいい。

僕はトラブルに見舞われながらこれらを順番に買うことになり、無駄な時間を費やしてしまった。




なんでそういう結論に至ったのか、順を追って説明しよう。


まず NAS について知らない人のためにざっくりとした説明を。


狭義には、LAN に接続できるハードディスクドライブ (HDD) 装置を NAS という。

PC に USB で HDD を接続することはできるが、これを LAN 接続で行おう、というものだ。

LAN 接続なので、多くの PC から同時アクセスできる。


(もともと SAN の逆、というパロディでもある。SANもネットワーク HDD 装置だけど、いろいろと逆なのだ)



NAS は最近はもっと多くの機能を提供していることが多いのだけど、いちばん重要なのは「大切なデータが壊れないようにする」機能だ。

そして、この最も基本的な部分に、RAID 技術がある。


RAID を単純に書くと「2台の HDD に同じ内容を書いておけば、片方が壊れてもデータは守られる」というものだ。代償として HDD の導入コストは2倍になる。




現在販売されている NAS 装置は、大きく分けて2系統ある。

買ってきてそのまますぐ使えるように、HDD などをすべて内蔵した製品と、HDD は別売りで自分で購入する製品だ。


一般に前者は初心者向けで、HDD を取り出したり交換したりすることは想定していない。

ここで問題になるのが、HDD が故障する前に本体が故障したらどうなるか、ということだ。


実は以前にその状態になったことがある。僕は技術を知っていたので HDD からデータを取り出すことに成功したが、普通はデータが失われると思っていい。

これでは、なんのための RAID なのかわからない。


HDD 別売りの機種は、当然のことながら HDD の取り出しや交換も想定している。

容量が足りなくなったらデータを残したまま増設する方法も提供しているし、本体が故障したら新しい(後継機の)本体に移し替えてデータを取り出せる、という保証もある。


ここまでの説明で、やっと冒頭の話につながる。


本体の故障だけでなく、後継機への乗り換えの際にも、以前の機種の HDD を移し替えるだけでいい、と公式には説明していた。


でもこの説明はかなり嘘だった、という話だ。


まず、設定は一部しか持ち越されない。

LAN 接続のための一番重要な「ネットワーク設定」は持ち越されず、デフォルトである DHCP 参照にされてしまう。


データ保全に必要な、バックアップの設定なども残ってはいたが使い物にならなかった。

バックアップ先となる「外部 HDD」の認識名が変更になったためだ。


僕の場合、後継機とはいっても、CPU の違う上位機種に乗り換えた。

そこで、NAS 上で使用できる機能なども細かく変更になったのだが、当然ながらそれらに関する設定も動かなくなった。


そしていちばん重要なことだ。

新しい機種で使えると期待していた「ファイルを保護する機能」が、旧機種から持ってきた HDD では使えなかった。


公式ページの説明では、今回の機種間の HDD の移行でもこうした機能制限は無いはずだった。

でも、公式ページの説明と違って機能は制限される。


HDD の載せ替えは、新機種への移行というよりは、本体故障時の緊急措置と考えたほうが良いのだろう。




仕方がないので、新しい HDD を購入することにした。


ちなみに、購入したのは IronWolf の 4T 。

NAS に入れる前に、表面に書いてあるシリアルナンバー (SN と書いてあるアルファベット混ざりの文字列)を2つとも控えておくといい。

(あとで NAS の設定画面から登録を行うと、3年以内に HDD が故障した際には無料でデータ復旧サポートを受けられる)


問題はその後だ。


新機種に古い HDD を入れると、自動的に認識されて新機種用の OS が書き込まれる。

だから、もうこの HDD を旧機種に戻すことは出来ないだろう。データが壊れるのが怖いので試してないけど。


旧機種はすでに使えず、新機種に新しい HDD を入れれば、古い HDD にアクセスする方法は失われる。じゃぁデータはどこから取り出せばよいのか。詰みだ。


これが、冒頭で旧 NAS を稼働したまま新 NAS を導入したほうが良い、と書いた理由だ。

そうすれば、旧 NAS から新 NAS に簡単・確実にコピーを行える。


僕は、幸いバックアップ用の外付け USB HDD があった。

NAS のデータはすでにバックアップされているが、念の為もう一度バックアップした。

(すでに書いたとおり、バックアップ用設定は動かなくなっているので新しく作り直した)


新しい HDD で新機種をもう一度設定した後、このバックアップを書き戻すことで無事復旧することができた。




さらっと「もう一度設定した後」と書いたが、ここにもハマリポイントがあるので書いておこう。


まず、設定をするには、新しい HDD を入れて NAS を起動したあと、WEB ブラウザで NAS にアクセスする必要がある。


この際、NAS には DHCP で IP アドレスが割り振られる。

(家庭内 LAN には DHCP サーバがあるだろう、という前提。DHCP とは、LAN に接続した機械に自動的にネットワーク設定を行う技術)


自動で割り振られた IP アドレスがどこになっているかは人間には分からないので、QNAP が提供する Qfinder というソフトを WIndows などにインストールする必要がある。

これを使えば IP アドレスを見つけ出し、その IP アドレスで WEB ブラウザを開いて NAS にアクセスしてくれる。


最初に HDD のフォーマットが始まる。これには数分程度かかる。


フォーマットが終われば、すぐに NAS として使い始められる。

実は裏で「RAID構築」と呼ばれる作業をやっているのだけど、それは1日も放置すれば勝手に終わるし、構築中でも別の作業は可能だ。


でも、ここがハマりポイントだ。まだ旧 NAS からのデータ移行をしてはならない。

この後の作業で全データを消すことになるから。


最初にやることは、「ストレージ&スナップショット」の設定に入ることだ。

ここから、Linux の技術の中でも難解な部類に入る LVM の設定を行う。


…いや、簡単に扱えるのが売りの NAS で、なんでこんな難しい設定を包み隠さずみせてるんだよ、と思う。

デフォルトにしろ、とまではいわないが、おすすめ設定とかで勝手にやってくれればいいのに。


HDD をストレージプールに登録し、ストレージプールから改めて「ボリューム」を作り出す。

ボリュームというのは従来の考え方で言うパーティションのことだ。


ボリュームは幾つかの方法で作り出せるが、シックボリュームで全体容量の6割程度にしておくといい。

また、「保護されたスナップショット領域」も確保する。こちらは2割程度で。


残りはシステムで使用する領域と「余り」になるわけだが、この余りはいつでも他の部分に追加できる。容量が足りなくなったときの予備だ。

従来のパーティションだとこうした動的な割当は出来なかったのだが、ボリュームなら可能だ。


これで、以降は「スナップショット」という、最新の便利機能が使えるようになる。

せっかく最新の NAS を買ったのだから、最新機能を使わないのはもったいない。




バックアップを書き戻しながら、RAID 構築を行いながら、NAS の設定もしていると、画面の左下のマスコット(謎のロボット。カイル君みたい)が、頻繁に目をバッテンにしながら「メモリ容量低下」と言っている。


なんだこれ、同時並行作業数が多すぎるのかな…と思いながら、このときは様子見にした。


翌日、RAID 構築もバックアップ書き戻しも終わった状態で、改めて各種設定などを行う。

まだ「メモリ容量低下」と言い続けている。


ここで気づくが、標準搭載の 2G のメモリでは、単純なファイルサーバーの状態でもメモリが足りないようだ。


頻繁に SWAP をおこし、プログラムが HDD の上で動いているような状態。

その HDD は NAS だからもともと頻繁に動かしているわけで、全体的に速度が低下する。


SWAP しても動いてはいるし、2G でも足りるだろうと考えて売っているのかもしれないけど…


いや、これむしろ「メモリは交換されるのが前提」だと考えて、一番安いメモリ搭載して売っているだろ。


増設用メモリを注文。

251D には SODIMM のメモリスロットが2つあり、最初は片方に 2Gbyte のメモリが入っている。


公式には、片方に 4Gbyte まで搭載可能。両方に搭載する場合は、同じメモリを搭載しなくてはならない。


ネットで探すと、今どき SODIMM は 8G が主流のようだ。

251D でも、公式にはサポートしないが 8G を認識するという報告がネットに散見される。


僕としては複雑なことをしたいわけではないので、倍の 4G あればいいかな…

とおもったが、後から気が変わったときに、もう一本全く同じメモリを買うのは多分無理だ。

4G 2本を購入。届いてから交換して 8G になった。


ネットによれば、相性問題が激しいらしくて、「動作確認できた」というメモリは人気商品になっている。

…Amazon ではすでに売り切れだったり、妙に高値だったりする。


あえて別の製品を選んでみる。

TIMETEC 社製のメモリ。4G SODIMM として最安値ではないが、それに近い価格だった。

アメリカの会社で、日本法人からの直販なので、問題が出たときのサポートもしっかりしていそうだ。


でも、問題なく動いた。すでに数日稼働を続けているが、相性による不具合は出ていない。


(もっとも、相性って個体差もあるので、他人が「相性問題出てない」と言ったとしても、あまり意味はない)




これでやっとまともに運用できるようなった。


251D は「後からパーツを購入して機能拡張できる」と人気の NAS なのだが、「後から」ではなく、最初にやらないとまともに動かないという話でした。


NAS の話、長いので一旦ここで区切る。


▲目次へ ⇒この記事のURL

関連ページ

251D 使用レビュー【日記 21/07/04】

別年同日の日記

04年 コンサート

13年 Mouse In Maze

18年 続・Unity


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -