目次
2019-05-17 洗濯機壊れた
2019-05-14 パソコンは買ったのだが…
2019-05-08 続：Minit
2019-05-05 パソコン壊れた
2019-05-04 Minit
2019-05-03 ServiceWorker と indexedDB
2019-05-03 令和
今月の日記
最近いろいろと壊れてばかりで、買い替えや修理で金がかさむ…
今回は、表題通り洗濯機が壊れた、という話だ。
我が家で一番古い家電品だった。
妻と同棲を始めたときに買ったものだ。
（結婚するつもりだったが、諸般の事情ですぐに結婚とはならず、しばらく同棲していた）
記録調べたら２０００年に買ってたよ。前世紀に買ったものだったのだな。
しばらく前から、調子が悪いことは気づいていた。
というか、５年位前にいったん買い替えるつもりで検討したりしていたんだ。
そのころに、一度調子が悪くなった…と思ったから。
でも、このときは排水溝が詰まっているだけだった。
排水溝が詰まったので、脱水ができない、というのがその時の症状だった。
掃除したら治った。
で、今朝。脱水ができずにエラーになった。
あぁ、また排水溝が詰まったか。…これは、すぐに掃除して、ちゃんと脱水できるようになったんだ。
脱水後、すすぎ動作に入るはず…のところで、またエラーになった。
確認すると、給水がおかしい。水がちょろちょろとしか流れない。
さて、問題はどこにあるだろう。切り分けを試みる。
洗濯機に給水するホースを外し、蛇口をひねると、普通に水が出た。
再び洗濯機につなぐと、水が出ない。
洗濯機の中の止水栓がおかしいようだ。
うーん、どうするか。
しばらく考えて、洗濯機を「すすぎ」動作にしてから、外したホースから水を入れて動かした。
「全自動」ではなく、水を入れる所は人がやらないといけないけど、とりあえず洗濯はできる。
とはいえ、このままでは生活が不便だ。
早速ネットで洗濯機について調べる。
…２０年の進化ってすごい。今の洗濯機、昔とは全然違うのね。
５年位前に調べたときに「あこがれの機能」だった、簡易乾燥機能とかは、安い機種でも当たり前についている。
２万５千円追加で出せば、ちゃんとした乾燥機能も付くのだけど…
これはしばらく考え、いらないと判断。乾燥機能は電気代が結構かかるようなので、「もったいない」とケチってつかわない自分しか想像できない。
現在、洗濯には風呂の残り湯を使っていて、汲み上げるポンプを使っている。
以前は、このためのポンプを内蔵した機種というのもあったのだけど…と調べると、今時どの機種でもついているのが当たり前で、当たり前すぎて売り文句にならないので、宣伝ページを見てもどこにも書いていない。
ドラム式か、縦型槽かは少し悩んだが、値段が全然違うので縦型で。
これには妻の好みも反映されている。僕自身はどちらでも構わない。
（洗濯はいつも僕がやっているので、本当は妻の好みを考慮する必要は、あまりない）
そのほか、いろいろ調べて、日立ビートウォッシュの、乾燥機能はないやつ（簡易乾燥はついている）の、8.0kg を買うことにした。
６月に新型が発売されるようで、旧型が安くなっていたから。
先ほどネットで頼んだが、設置は来週半ばの予定。
それまでは、少し不便だけど、給水は手動で行う全自動洗濯機を使うことになる。
ところで、最近頻繁にものが壊れるので、日記の中から拾い出してみた。
パソコン（２０１９年５月仮復旧しているが調子悪い。代替機購入済み）
クレジットカード（２０１９年２月不正利用が発覚し再発行）
冷蔵庫（２０１９年２月買い替え）
エアコン（２０１９年２月修理）
布団（２０１９年２月買い替え）
自動車パンク（２０１９年２月）
サーバー（２０１８年１２月買い替え）
エアコン（２０１８年１２月買い替え・子供部屋に増設）
ノートパソコン（２０１８年１１月 HDD不調で交換修理）
無停電電源装置（２０１８年１０月買い替え）
自動車（２０１８年１０月車検１８年目を前に買い替え）
電話機（２０１８年８月買い替え）
食洗器（２０１８年３月修理）
ＩＨキッチンヒーター（２０１７年９月修理）
給湯器（２０１７年８月修理）
ネットワークルータ（２０１７年３月買い替え）
家（２０１７年１月～２月メンテナンス）
まぁ、２年前まででとどめておこう。
ここに「家のメンテナンス」が入っている。建築後１０年で行うように、ハウスメーカーが推奨しているものだ。
つまり、ものが壊れる理由は、家を購入したときに併せて買ったものが、１０年たって寿命を迎えてきているという、多くはそれが理由だ。
実は、日記に書いていないが、１月ほど前に庭の修理もやっている。
家を建てたとき、金がなくて外構は自分たちで（というか、主に妻が）やった。
歩道を枕木で作ったら、１０年で朽ちてボロボロになり、先日業者を入れて枕木風のコンクリート製のブロックを入れてもらったのだ。
業者さんは綺麗に入れてくれていたのだけど、妻はしばらくして「どうも、思っていたレイアウトと違った」と言って、コンクリート枕木を大幅に並べなおした。
最初の枕木も自分で並べたのだから、材料さえあればできるだろう、という算段で。
しかし、上に車が乗っても割れないような、中空ではないしっかりとした枕木なので、かなり重かったらしい。
幅25cm 、厚さ15cm、長さ最大 1.2m…かな。標準的なコンクリートの密度で計算すると、１本 100kg くらいだね。
（標準的なコンクリートの密度は、2.3t/m^3 らしい）
作業後、２日くらい体中が筋肉痛だと言っていた。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、パソコン壊れた、と書いた。
７年も使っていたマシンで、以前から時々調子が悪かった。
さすがに仕事のメインマシンが壊れるのは困る。完全に壊れる前に買っておこう、と早速注文。
今使っているマシンは DELL だが、７年前は DELL はダントツにコストパフォーマンスが良かった。
しかし、今調べると DELL も悪くないが、HP もいい感じ。
実は、半年前には妻がメインマシンを買い替えていて、調べた結果 HP にしている。
僕も HP に決定。
CPU 性能は低くてもいいが、メモリは多くほしい。
仕事柄、サーバーに接続して使う端末になりがちなので、CPU 性能はそれほどいらないのだ。
しかし、Chrome で同時に何ページも開いたりするので、メモリは食う。
あと、メインストレージは SSD がいいのだけど、SSD だけではさすがに足りない。
HDD と同時搭載がいい。
DELL の安いマシンは、SSD のみでメモリ増設もできない、というものが多かった。
少し高級機種になると、SSD+HDD でメモリも増設可能、というのがある。
しかし、それは高級機種なので CPU も i7 で、高い。
これに対し、HP は CPU が i5 のまま、SSD+HDD メモリ増設が選べた。
そんなわけでそちらを選ぶ。
「令和改元セール」を銘打って安かったのも後押しした。
ところが、だ。
さんざん比較してよいマシンというのは、他にも良いと感じる人が多いようで、注文殺到だそうだ。
５月７日に注文してすぐに「在庫がなくなってしまい、出荷時期のめどが立っていない。もう少し待ってほしい」というお詫びのメールが来た。
それから２日置いた５月９日、再び「納期に関するご案内」というメールが来た。
納期が決まったか、と思って開くと、「出荷のめどが立たない」というお詫びだった。
まぁ、仕方がない。
今のマシンは調子が悪いというだけでまだ使える。気長に待とう。
…とおもっていたら、スリープして再起動したときに、回復不可能なエラーが出て止まった。
再起動したらちゃんと動いたのだけど、やっぱりこのマシン不安だ。速く新しいマシン来ないかな。
で、先ほど、またメールが来ていた。
「納期に関するご案内」…やはり「出荷のめどが立たない」だった。
前のメールから５日、注文からは１週間たったので、現在の状況を報告ということだろう。
ただ、文面は少し変わっていて、「納期が決まり次第メール連絡、また、納期が決まらないまま４営業日立った場合もメール連絡」と確約している。
人気があって商品がない、というのは仕方がない。
その際の対応として、現在の状況を逐一知らせるというのは、対応としては及第点だろう。
一応、前のメールから、まだキャンセルは可能であること、急ぎの場合は即出荷モデルも提供できることも書かれている。
僕としては、また７年くらい使ってしまうだろうから、ここで妥協して別モデルにしようとも思っていない。
今のパソコンは調子悪いとはいえ十分使えているので、気長に待つことにしよう。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
MINIT 最小プレイ回数クリアチャレンジ
— wizforest (@wizforest) 2019年5月7日
まだ減らせそうだけど､とりあえず満足｡
#NintendoSwitch pic.twitter.com/s5N0A2YReR
先日、Nintendo Switch 用ゲーム Minit の話題を書いた。
ゲーム的には「初代ゼルダの伝説のような」ゲームなのだけど、クリアしてみて、これはピクミンのように「ゲーム中での最短時間を目指すものだ」と思った。
ピクミンは、「１日」の概念があるゲームで、その日の終わりにはすべてを終了して撤収する必要があった。
その状況下で、できるだけ少ない日数でクリアを目指すゲームだった。
それに対し、Minit は「１分」で強制的に作業が中断され、スタート地点に戻されてしまう。
ゲーム終了時に、スタート地点から出発した「スタート回数」が表示されるので、この回数を減らすことを考える。
まずはヒントなしで…と頑張って、冒頭に書いたスクリーンショットを得た。
１２回。もっと減らすことができるポイントはわかっているのだが、それをやるのはかなり難しそうに思う。
ひとまずはこんなところだろう。
じゃぁ、答え合わせをしよう。
すでに発売されて半年たつゲームだから、そういう攻略記事もあるだろう、とネットを探してみる。
…全然見当たらない。この遊び方、誰もしていないのか？
スクリーンショットにもわかるように、下に所要時間がかかれている。
こちらの時間を競う RTA （Real Time Attack）の方が盛り上がっているようだ。
現時点では、エンディングに表示されるゲーム内時間で 6分53秒43、というのが最高記録のようだ。
RTA では、時間短縮のために自殺するのはかまわないので、回数は 14回。
動画も見てみたが、これはこれですごいのだけど、回数短縮の参考にはなりにくい。
ただ、知らない時間短縮テクニックを知ったので、これを使えばもう少し時間短縮できそうだ。
＃砂漠のオアシスって、ずっと遠くにあるのだと思っていた…
砂漠での「画面切り替え回数」が重要で、距離ではないのね。
さらに探してみると、やはり回数記録に挑んでいる人はいるようで、「１０回」でのクリア方法解説を見つけた。
この解説で見る限り、上に書いた時間短縮テクニックを使っているようだ。
＃そのオアシスが遠いので、そこにいる敵を倒して戻る、は不可能だっと思っていた。
それだけでスタート１回分を使っていたのだけど、それを減らせれば大きい。
そして、この解説では「最低９回でクリアできるけど、難しいので１０回を目指そう」という形で書かれている。
なかなかこういう記事が見当たらないと思ったら、もう発売から１年近いゲームなので、みんなこの段階は通り過ぎて RTA に行っているのだな。
まずは１０回を目指すか…。
難しそうではあるが、独力でも１２回を達成できたのだから、無理ではない気がする。
しかし、疲れたのでいったんハードモードをのんびり遊んだ。
ハードモード難しい。でも、何度死んでもいいや、というつもりでやっていれば、何とかなる。
クリアできた。
そして、「マリーモード」が現れた。
マリーは、ゲーム中にヒントをくれる幽霊の名前。マリーモードでは、主人公がこの幽霊になっている。
そして、幽霊なので死なない。自殺はできるけど、１分の時間制限はない。
そこで「最短スタート回数」を目指してプレーした。当然、１回のスタートで最後までクリアできた。
＃時間制限がないとはいえ、敵との戦闘はある。
普通は死んだらダメージ回復になるので、マリーの１回クリアはミスが許されない、という意味でもある。
ハードモードのアイテムをまだコンプリートしていないので、それをやってから１０回に挑戦…かな？
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
パソコン壊れました。
とりあえず修復できたからこの日記を書いているのだけど…
僕は現在町内会の役員をやっていて、今日は町内会の総会がある日です。
これを書いているのは午前で、先ほど会場設営をしてきました。
総会自体は午後にあります。
そこでちょっと書類仕事を頼まれてきたので、PCを起動しようとしたら…
え？ 起動できないって言って自動修復フェーズに入ったよ？
そして、「修復できません」ってさじを投げられたよ？
どうしてこういうタイミングで壊れるのか。
…いや、わかっている。自分のせいではある。
もう７年も使い続けているマシンで、「そろそろ（壊れる前に）買いなおさなきゃ」と言ってから半年以上たっている。
それにしたって、このタイミングで。
マシンは７年前のものだが、昨年の１２月に、Windows再インストールをしている。
新しいサーバーを購入し、古いサーバーの SSD が余ったのでメイン PC につなぎ、そこに Windows を入れてみたんだ。
これが結構快適だったのも、新マシンをいまだに買っていない理由になっている。
しかし、中古の SSD って、だめだよね。壊れやすいよね。
きっと、自動修復できない理由もそれだよね。
しかし、「新しいストレージに新しい OS を入れた」ということは、古いストレージに古い OS が残っているということでもある。
そちらから起動してみたら、ちゃんと起動できた。
そして、SSD のエラーチェック。やっぱりエラーが出た。
「修復」を試みる。…あら、ちゃんと修復できた。
これで再起動。問題なく再起動できた。
そんなわけで、一安心してこれを書いている。
しかし、いよいよ新マシン買わないとなぁ。
まだ、昨年１２月に始めたサーバー設定も終わっていないので、そちらが終わってからにしようと思ったいたのだけど。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ゴールデンウィーク前の話なのだけど、ニンテンドーポイント（ゴールド）が４月末に失効するよ、というお知らせが来た。
何か買ったりすると付くポイントで、ゴールドは１ポイント＝１円で任天堂商品の購入などに使うことができる。
ちなみに、プラチナポイントというのもあるのだけど、こちらはゲーム内でバンバン配布し、ゲーム内以外ではあまり使い道がないゴミみたいなものだ。
で、失効するゴールドポイントは 150ポイントだったのだけど、せっかくなので全保有ポイントを調べたら 937ポイントあった。
500円程度のダウンロード販売のゲームを買ってもよいかも。いや、少しお金出して 1000円くらいのものを買った方が楽しめるか。
というわけで、いろいろと悩みながら「Minit」というゲームを買った。
Switch 版は昨年夏に発売になっているし、それ以前に PC 版で販売されている。
だから「今更」感のあるゲームだろう。
しかし、なかなか面白かった。
というか、一通り解き終わった後で「これからが本番だ」と気づき、今一生懸命遊んでいる。
まずはゲームの説明だ。
ネットを探せば宣伝動画などもあるので、そちらを見たほうがわかりやすいけど。
まぁ、初代ゼルダの伝説タイプのアクション RPG だと思いねぇ。
ただし、主人公は呪われていて、６０秒たつと死んでしまう。
死ぬとセーブポイントから再スタートになるが、死ぬ直前までに「世界に影響を及ぼす」行為をしていた場合は、その影響は残ったままになる。
以上。シンプルだが、それだけのゲームだ。
ゼルダと同じように、画面切り替え型で広い世界を探検する。
ゼルダと同じように、剣を前に突き出して敵を倒したり、障害物を壊したりできる。
ゲーム画面は白黒のドット絵だ。ゲームボーイみたい、というとほめすぎ。
ゲームボーイは白黒４階調だったから、このゲームの画面よりももっと美しい。
しかし、この白黒画面が、ゲームを面白くするためによく考えられているのだ。
６０秒で死ぬまでに、世界に影響を及ぼせばいい。
だから、ひたすらいろいろなことを試してみて、何が起きるのか探す必要がある。
洞窟を見つけて入ってみるが、真っ暗で何もわからない。
どうやらライトが必要なようだが、どこにあるのかわからない。
灯台を見つけたが、鍵がなくて入れない。冒険していたら鍵を手に入れ、灯台に上ってみたらライトが置いてあった。
世界に影響があるのは、上の例でいえば「鍵を手に入れる」「ライトを手に入れる」など。
基本的に得たアイテムは死んでもなくならないし、切り開いた道などもそのままになる。
一方で、倒した敵などは死ぬと復活する。動かせるものも、死ぬと元の位置に戻ることが多い。
何よりも一番影響があるのは、「セーブポイントに入る」ことだ。
基本的には、ベッドが用意された家がセーブポイントになっていて、死んだときは「最後に入った」セーブポイントに復活する。
世界には何カ所かのセーブポイントがあり、そこを中継地点とすることで広い世界をくまなく冒険することができる。
このゲームの中にはパズルが多く、障害物の動かし方などに失敗すると詰んでしまうことがある。
また、袋小路の行き止まりもあり、そういう場所にはアイテムが置かれているのだけど、アイテムを取った後脱出することができない場合がる。
まぁ、時間切れになれば死んでセーブポイントに戻るのだけど、B ボタンを押せばいつでも自殺できる。
この「自殺」は、遊び方によっては非常に重要なポイントになる。…ようだ。
さて、先に「白黒画面がゲームを面白くする」と書いたのだけど、白黒でも古臭い感じはしない。
アニメーションがやたらと滑らかだからだ。ファミコンやゲームボーイの時代なら、こんな滑らかなアニメーションは作れなかった。
しかし、色がない、ドットも荒いというのは、情報が極端に少ない。
…ここが重要だ。世界を冒険するときに、初めて見たものの意味が分からないのだ。
もしくは、意味が分からないがゆえに、「そこにあるものが見えていない」ともいえる。
意味が分かるのは、それが重要アイテムだと認識されて以降だ。
つまり、このゲームは世界に影響を及ぼすためにアイテムを捜し歩くゲームなのに、そのアイテムは入手するまで「見えていても気づかない」ことが多い。
なんて巧妙な隠し方だろう。
ちゃんとヒントを見せているにも関わらず、それがヒントだったとわかるのは謎を解いた後なのだ。
「こんな隠し方、わかるわけないよ！ 不条理だ！」と怒りたくなるのはクソゲーの条件だし、そう怒りたくなる場所が随所にある。
しかし、あとで見直してみると、明らかにわかるように置いてあるのだ。気づかなかった自分が悪い、と納得するより他にあるまい。
ちなみに、もし気づかなかったとしても、あまり問題はない。
必須アイテムは比較的楽に入手できるようになっていて、巧妙に隠されているのはコンプリートを楽しむオマケ要素だから。
ところで、このゲームのとあるところに、謎のメッセージが置かれている。
???
???
???
と、ハテナマークが並んでいるだけなのだ。
一度クリアした後、続きを遊び始めた。
アイテムのコンプリート要素があるので、ゲームをクリアした後でも、そのセーブデータで遊び続けることができる。
そこで気づいた。一番上の ??? に、「ノーマル：243」って入っている。
ん？ これはなんだ？ その時は気にせず遊んでいた。
そして、アイテムコンプリートが難しいので、気を取り直してもう一度最初から遊んでみた。
最初から遊びなおした理由は、設定画面の中に「スピードラン」という項目があるからだ。
初期設定では OFF になっているが、ON にしてゲームを始めると、ゲーム開始からの1/100秒単位の通算時間カウントが画面上に表示される。
つまり、これはやるべきことを効率よくやって、タイムアタックをするゲームなのだな、と認識したのだ。
２回目は、謎を全部知っているので３５分ほどで終了することができた。
（ちなみに、最初のプレイは１日１～２時間で１週間程度、通算では５～６時間くらいかかっていると思う）
で、そのあと気づいた。??? に書かれていた 243 が、44 に減っている。
この 44 というのは、クリアまでに「死んだ回数」だ。
ここでやっと気づいた。
このゲーム、スピードランもできるけどそれはオマケ要素で、作者が一番やってほしいのは「少ない死に回数でクリア」なんだ。
現在死に回数を減らすべく、冒険の手順を組み立てている。
１分間にできるだけ多くのことを詰め込まなくてはならない。
最初の一分は何度もやったので、もう動きが確定している。
先ほど書いた例の「灯台に上ってライトを取る」ところまでは、最初の１分で可能だ。
ちなみに、初回プレイではそこまでに１０回以上は死んでいたと思う。
それ以降は、大まかにやることは決まっているのだけど、まだ無駄のない動きというのがわかっていない。
現時点でのベストスコアは２１回だけど、まだ無駄が多いので２０回を切るのは余裕だろう。
最終的にどのくらいまで切り詰められるのかはまだ見えていない。
そして思った。
この作業、ピクミン１の楽しかった部分だ。
やるべきことはわかっている。
でも、手順の一部には前後の入れ替えが可能な部分がある。
そうした部分を調整しながら、区切られた時間を最大限に使う方法を考える。
小さなパズルを解き、その答えを大きなパズルの一部としながら、大きなパズルを完成させていく。
状況次第では、小さなパズルの答えを一度壊し、再度組みなおすことで大きなパズルがより完成に近づく場合もある。
ピクミンと違い、途中までできたところでセーブデータをコピーして保存して次に挑む、ということができない。
最後まで通しでやらないといけない「一発勝負」なので、解き方は再現性が高い、偶発性を排除した方法であるのが望ましい。
一方で、ピクミンと違い、全部通してやっても３０分以内だ。
気軽にチャレンジしやすい。何度も繰り返すことで見えてくる攻略もあるだろう。
実はこのゲーム、ハードモードもあるのだけど、まだハードモードはクリアしていない。
ハードモードは、名前の通りハードだ。難しい。
ノーマルモードの徹底攻略と、ハードモードのクリアのどちらを優先すべきかわからないのだけど、とりあえず「楽しい方」を遊んでいる。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
「ゴールデンウィーク明けにはリリースしたいので、その前までにお願いね」
と言われていたプログラム改良があった。
その改良は、ちゃんと四月半ばまでに仕上げた。
WEB ブラウザ側で動く Javascript のプログラムだったのだけど、同時にサーバー側も変更することになっていた。
サーバー変更は僕の仕事ではなかったのだけど、そちらが間に合っていない。
急遽、Javascript 側で何とかできないかと、ゴールデンウィーク直前に ねじ込まれた。
目的は、URL の一部隠蔽だ。
ブラウザ側プログラムの改良により、画面遷移が一段階へり、目的画面の URL が変わることになった。
この URL にはセッション情報が含まれており、見えているのが好ましくない。
そこで、セッション情報を URL に入れるのではなく、POST にするか、Cookie にするなどして、消すことになっていた。
つまり、これらはサーバー側の改良だ。
それができなくなったので、Javascript 側でどうにかならないか、というのが、追加の依頼だった。
セッション情報はややこしい文字列になっているので、長い時間表示されているのでなければ、一瞬なら出てもよいという。
つまり、セッション情報付きの URL でアクセスしてから、取得したページの Javascript の中ですぐに URL を変更し、消せればいいということだ。
ただし、該当ページは都合上、時々リロードする場合がある。
セッション情報なしではサーバーにアクセスできないので、リロードする際にはすぐに URL を元に戻したい。
URL を変更するのは簡単だ。history.replaceState 関数を使うと、現在アクセス中として表示されている URL を変更することができる。
いわゆる ajax …画面遷移を伴わないサーバーアクセスを行うようなプログラムで多用されているテクニックだ。
だから、セッション情報がない URL にすることはできる。
この時に、本来の URL を変数に保存しておいて、リロードの際に元に戻せればいいだろう。
しかし、javascript に「リロードイベント」というのは存在しない。
＃イベントとは、「何かが起きた」とプログラムが知ることができる、概念上の存在。
Javascript では、特定のイベントに対してプログラムを紐づけることができ、紐づいたプログラムは、イベントが起きると自動的に実行される。
これにより、イベントが生じたらプログラムを動かす、ということが可能になっている。
リロードされたかどうかを知る方法はあるのだが、それはリロードされた「あと」のページで検知できるだけだ。
そして、リロードの際には表示している URL にアクセスが行くので、そのままではセッション情報がないためにサーバーから拒否される。
リロード「あと」のページの表示自体が行えない状態で、リロードに伴う不都合をこの方法で解消することはできない。
「ページが終了した」というイベントはある。unload イベントだ。
しかし、Javascript プログラムの寿命は、そのページが終了するまでだ。
そのため、unload イベントにプログラムをセットしておいても、実行されることはない。
実行されないんじゃ意味ないじゃん、ってことで、beforeunload というイベントもある。
「unload の直前」というイベントだ。
よく、「ページを離れてもいいですか？」というダイアログが表示されるのは、このイベントの時に動くプログラムによるものだ。
このイベントは、次にアクセスする URL が決定し、新しいページの取得準備が整うと呼び出される。
つまり、このイベントの中で URL を書き換えても、すでに URL は決定していて意味がない。
このイベントでできることは、新しいページへの移行を中断し、今のページに居続けるかどうかをユーザーに問いかける、ということのみだ。
そんなわけで、ブラウザ側の Javascript で解決するのは無理とわかった。
でも、まだ最後の望みがあった。
一般に「ブラウザ側の Javascript」というのは、WEB ページに付随するものだ。
しかし、最近のブラウザには、WEB ページではなく「ブラウザに」Javascript を登録し、動かす方法があるのだ。
ServiceWorker という。
Chrome/FireFox では早くから実装され、便利なので使いたいプログラマも多かったのだけど、Safari ではなかなか実装されなくて使いどころが限られていた。
昨年、やっと Safari も対応したので、使われる局面が増えてきている。
これを使うと、WEB ページがサーバーに問い合わせた瞬間に、そのリクエストを横取りして、Javascript がサーバーの「ふりをして」返事を返したりできる。
だから、オフラインなのにキャッシュしておいたデータを渡したり、逆にサーバーにデータを送ろうとしたときにキャッシュしておいて、あとでオンラインになった時にこっそり送信したりできる。
Google Docs がオフラインでも使えるのはこの仕組みを使っているからだ。
Android では、この仕組みを使って WEB ページを「アプリ化」することもできる。
WEB ページに行くと「このページをインストールしますか？」と促され、インストールを選ぶとホーム画面にアイコンが現れる。
このアイコンをタップすれば、いつでも WEB ページが提供する機能を使える。
Google Docs の例と同じように、適切に処理されていれば、オフラインでだって使える。
Service Worker の利用例は、多くは「WEB を オフラインでも使えるようにする」のと、それをさらに拡張した「アプリ化」だ。
だけど、先に書いたように、サーバーへのリクエストを横取りして、いろいろなことができる。
キャッシュデータを渡してオフラインでも動くようにする、というのは代表的な応用例にすぎない。
これなら、リロードの問題を解決できそうに思えた。
…一筋縄ではいかなかったのだけど、実際解決できた。
基本戦略はこうだ。
・WEB ページ側で、history.replaceState を使って URL を一部削除。
同時に、削除前の URL を ServiceWorker に渡して、データ保持。
・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、
保持していた本来の URL にアクセスし、そのデータを WEB ページ側に渡す。
実験過程を端折るが、実際にこの流れを作ったらうまく動かなかった。
WEB ページ側で動いている Javascript は、内部でセッションデータを使用していたのだ。
（僕は途中から参加して改良してきただけなので、そうした部分があるのを知らなかった）
だから、サーバーアクセスの際の流れを少し変えることにした。
・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、
保持していた本来の URL にリダイレクトする指示を作り出し、WEB ページ側に渡す。
リダイレクトが挟まるので、WEB ページ側としては少し動作が遅くなってしまう。
しかし、一度本来の URL に戻ってからリロードすることになるので、内部で動作するプログラムでも
URL に入れたセッションデータを使えることになり、問題は出なくなる。
さて、実際に作る上では、いくつか問題があった。
一番重要なのが、Javascript の生存期間だ。
WEB ページでは、そのページが存在する間、Javascript が生存する。
変数などもこの間は保持されるので、データ保持も変数に入れればよい。
しかし、ServiceWorker では、生存期間の考え方が二つあるのだ。
先に書いたように、ServiceWorker はブラウザ側で動き、WEB ページが閉じられても残り続ける。
しかし、それは「残っている」だけで、生きているわけではない。
じつは、必要な時に動作し、動作を終わるとすぐに終了してしまうのだ。
「データを渡す」という動作があったとしたら、その動作が終わった瞬間に終了し、変数は消える。
その後、「サーバーアクセス」という動作があり、動き始めたときには変数は存在していない。
だから、変数ではない方法でデータを保持しないといけない。
ServiceWorker は非常に強力な仕組みなので、悪さができないように厳しい制限が課されている。
データ保持方法としては、indexedDB しか使えない。
古くから知られるデータ保持方法には、Cookie や webStorage があるが、それらよりも新しい仕組みだ。
まぁ、それしか使えないのであれば、それを使おう。
…これが、イベントで動作する仕組みになっていて使いにくい。
DB に接続する、という指示を出すと、少し後で「接続成功」というイベントが起きる。
だから、接続成功イベントに、接続後のプログラムを登録しておく。
接続後には、アクセスしたい対象を指定してから「データ取り出し」を指示する。
しかし、データはすぐ取り出されるわけではない。少し後で「取り出し成功」イベントが起きる。
だから、ここでもイベントに対してプログラムを登録しておく必要がある。
非常に面倒くさい。
しかし、他に方法はないのでその方法でプログラムを組む。
ところが、もう一つ問題があるのだ。
ServiceWorker 自体は、こうしたイベントによって動くモデルではないのだ。
いや、先に書いたように「サーバーへのアクセスが生じた」などのイベントはある。
でも、Javascript ってとにかく「何かしたら後で呼び出して」という書き方が多くて、ここ数年で新しい書き方が取り入れたのだ。
そして、ServiceWorker は、基本的にその書き方で書かれないといけないようになっている。
この書き方は Promise というやつで…
この概念の歴史から入ろうと思ったが、無駄に長いのでやめた。
同時に、概念だけ説明するのも同じくらい長くなるのでやめた。
ともかく、概念自体は古いとはいえ、10年たっていないのではないかな。
Javascript の言語仕様に取り入れられたのは、2015年なので、４年程度しかたっていない。
しかし、便利なので、これまでイベントモデルで作られていた Javascript が、最近は Promise モデルで機能追加されるようになってきている。
上に書いたが、ちゃんと理解していないと混ぜて使えない。
ちなみに、Promise の概念の前に Deferred があり、こちらのことは以前に書いたことがある。
微妙に違うとはいえ、概念的に慣れていたのですぐに…でもないけど、１日程度で理解できた。
そんなわけで、同じことで悩んでいる人にとっての「答え」を示そう。
ServiceWorker では、fetch （URL アクセス）イベントに対して、最終的な「返事」を event.respondWith として返せばよい。
ここで、返す内容は Promise でなくてはならない。
Promise は、resolve を引数とする関数として定義される。
resolve はコールバック関数であり、Promise の処理終了時には、resolve を呼び出してやらなくてはならない。
この時、resolve には、「結果」を引数として渡す。
通常の関数における、return と同じような感じで、何が結果になるのかはその時の処理内容による。
respondWith は、URL アクセスに対する答えを返す関数なので、答えは http の Response となる。
これは Response クラスとして定義でき、リダイレクトしたいなら headers の Location に URL を渡せばよい。
（http と同じだ）
以上の「きまりごと」さえ守れば、あとはどんな書き方をしようとも自由だ。
関数内部で indexedDB のイベント呼び出しをたくさん定義しても構わない。
僕が仕事で必要だった関数の場合、次のようになった。
self.addEventListener('fetch',function(event){
let url = event.request.url;
let param = url.match(/targetDirectory\/([0-9]+)(\?session=)?/);
if(!event.isReload || !param || param[2])return;
event.respondWith(new Promise(function(resolve){
let openReq = indexedDB.open('targetDB');
openReq.onsuccess = function(event){
let db = event.target.result;
let trans = db.transaction('fullURL','readonly');
let store = trans.objectStore('fullURL');
let getReq = store.get(param[1]);
db.close();
getReq.onsuccess = function(event){
let redirectResponse = new Response('',{
status: 302,
statusText: 'Found',
headers: {
Location: event.target.result.url
}
});
resolve(redirectResponse);
}
}
}));
});
説明しておくと、/targetDirectory/123?session=**** というような URL が隠蔽対象だ。
リロードにより fetch イベントが起きているときは、すでに隠蔽されて ?session= 以降はなくなっている。
しかし、初回アクセス時や、リダイレクト直後は ?session= 以降もついているので、判別して処理を変える必要がある。
そして、123 の部分の数値はページの分類を示していて、ブラウザの複数のタブで開かれる可能性がある。
それぞれでリロードしたときに混乱しないように、123 を DB のキーとして、元の URL を格納してある。
＃格納部分のプログラムは別途必要。そちらは Promise と無関係に書けるので、それほど難しくない。
…というわけで、URL を検査して、隠蔽されていない場合はそのままアクセスを通す。
隠蔽されている場合は、123 にあたる部分をキーとして DB を検索し、得られた URL へのリダイレクトを生成する。
ちなみに、僕の要件ではリダイレクトが必要だったが、URL を差し替えてそのままサーバーにアクセスしたい、という場合もあるだろう。
実はそちらの方がプログラムは簡単で、redirectResponse を生成せずに、
resolve(fetch(event.target.result.url));
としてしまえばよい。
ここで重要なのは、
・fetch イベントに対する反応は、すぐに返さないといけない。
・event.respondWith が呼び出されれば、そこで帰ってくる反応を待つ。
・呼び出されなければ、本来の URL に対してアクセスを行う。
ということだろう。
respondWith は「結果を返す関数」ではなく、「結果を返すと約束する関数」だ。
結果を返すものだと思って、結果が出てから呼び出そうとすると、「fetch に対して respondWith が返されなかった」ことになり、本来のサーバーにアクセスが行ってしまう。
そして、結果を返すと約束するのだから、返すのは Promise （約束）だ。
Promise は、最終的に resolve として渡される関数を呼び出しさえすれば、その内部でどれほどの時間がかかっても構わない。
だから、時間がかかる indexedDB の処理は、この Promise 内部で行うようにする。
…ただこれだけのことだ。
プログラム例を示したら、なんてことのない、当たり前に見えるコードだろう。
けど、こういう例がネットを探してもなかなか見つからないんだ。
ServiceWorker というと、「キャッシュを使ってオフラインでも動作するようにしましょう」ってお決まりのパターンばかりで。
＃ちょっと気が利いた例では、簡単な文字列を「WEB ページ」として生成して返したりする実験をしていた。
しかし、indexedDB を使って何かのデータを返すような処理を見つけることはできなかった。
この日記が、同じような処理をしようとしている人の助けになれば幸いである。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
タイトルは内容と無関係。
とりあえず、天皇が代替わりして元号が変わりましたよ、という記録として。
そして、記録なので、多くの人が知っているあたりまえのことの説明から始める。
さて、長すぎるゴールデンウィーク。
今年は代替わりの影響で、天皇誕生日がない。
そこで、即位の日である５月１日が祝日に設定された。
４月２９日は昭和の日で、５月３日は憲法記念日で祝日だ。
ここで、５月１日が祝日になると、「前後を祝日に挟まれた日は休日」というオセロのようなルール（国民の祝日に関する法律 第三項第三条）によって、４月３０日と５月２日は休日となる。
このオセロルール、もともとは憲法記念日の５月３日と、こどもの日の５月５日に挟まれた５月４日を休日にするために作られた。
1985年、バブルのころに作られた法律だ。
当時は、日本人は働きすぎだ、と思われていた。一方で、バブル景気で長期休みを取って旅行する人も多かった。
そこで、休日を増やせば旅行などで消費が増え、一石二鳥！ と作られた法律だ。
その後、同じような考えで連休を作り出すためにいくつかの祝日が、日付固定から「月曜日」に移動され（いわゆるハッピーマンデー法案：1998年成立）、その結果、本来は離れていた敬老の日と秋分の日が近くなり、上に書いた「祝日に挟まれた日は祝日」ルールが不意に発動したりするようになった。
ちなみに、日本は世界的に見ても祝日が多い、「平日」が少ない国だそうだ。
働きすぎだと言われるのは、休日がないからではなく、休日でも働いたり残業するのが当たり前だったりする雰囲気が作られているからだ。
休日を増やしたからと言って働きすぎが解消されるわけではない。
いきなり話がそれ気味だが、毎年ゴールデンウィークには有給休暇を混ぜて長い連休を作る人がいる。
しかし、今年はそんなことをせずとも、カレンダー通りで１０連休となった。
…休みが長すぎて、「そんなに休んでいるわけにはいかない」と働いている人・働かざるを得ない業界続出だけどな。
通常のゴールデンウィークなら、有休を使って連休に「する人もいる」だけなのである程度緩急があり対応しやすいが、今年はみんな連休だから。
かくいう僕も、２４時間稼働しているサーバー関連のお仕事もしているために、ゆるく仕事を頼まれていたりする。
管理をお手伝いしているあるサービスでは、５月１日に内容更新があった。
プログラム変更を伴ったので、僕も作業した。
そしたら、管理担当者は、いつも西暦で書いている「更新情報」に、いきなり「令和元年５月１日更新」って書きやがった。
まぁ、書きたくなる気持ちはわかる。次回からはまた西暦に戻すそうだ。
こんなゴールデンウィーク中に出かけたら、混みすぎていて楽しめないだろう…と、我が家ではどこにもいかないよ、と子供にあらかじめ宣言してあった。
その代わり、家の中で楽しめそうなことはする。
一応、「どこか行きたい」という気持ちの対策として、４月２１日の次女の誕生日にはキッザニアに行ってあるしね。
２６日には、長女の誕生日パーティも家でやっている。
２９日は、妻が家の庭の手入れなどしつつ、庭でバーベキュー。
焼き鳥 50本と、ハーブ入りフランクフルトを買ってきた。買いに行ったら、スーパーがいつもより混んでいて驚いた。
３０日、出かけないといいつつ、陽光台にある子供宇宙科学館へ。
この日は雨だったし、祝日ではなく「休日」だったので、多少人出が少ないだろうと思ったんだ。
でも、朝早くから出て、１０時過ぎには到着した。
科学館は９時半オープンなのだけど、入り口前に行列ができていた。
科学館に行ったのは、以前から長女が行きたがっていたから。
また、次女が小学校でもらってきた科学館のチラシに、「暦」をテーマにした小さなイベントをやると書いてあったから。
（僕は暦好きです。チラシを見ただけで内容はだいたい想像できたけど、知らないこともあるかもしれないので見てみたかった）
行列が長くて入れそうにないし、雨も降っているので、すぐ近くのどんぐりハウスへ。
小学生の向けの無料施設で、本来は両親共働きの小学生が、放課後に大人の保護下で遊んで待つことができる施設だ。
実は、長女が「科学館に行きたい」と言っていた理由の半分は、こちらに来たかったからだ。
すぐ隣の施設なので、行くときはセットで考えていたのだな。
子供が遊んでいる間に、妻が科学館の様子を見に行ってくれた。
人が多すぎて入場制限をしているようで、列はさらに伸びた、と報告。
２時間弱遊んだが、あきらめて帰ることにする。
子供の洋服が少し足りない感じなので、デパートに行って買い物して帰ろう。
…というわけで港南台に行ったら、駐車場が混んでいてなかなか入れない。
みんなで車に乗っているのは無駄なので、妻と子供にはおりてもらい、先に昼ご飯を食べててもらう。
30分ほどかけてやっと駐車し、合流。僕も軽く食べて買い物へ。
ユニクロに行ったら、スプラトゥーンＴシャツを売っていた。
子供も欲しがるので、良し買うか！ と子供コーナーに行ったら、売り切れていた。
あるのは大人用のみ。
ネットで調べたら、ネット店舗ではまだあるようだ。ネットで買うことにする。
（夜、家族全員分を買った。５千円分買わないと送料かかるから。）
それ以外に、長男の服が足りないので数着購入。
この日は、以上。どこ行っても混んでいる、と分かったので家に帰って夕食食べました。
夕食は、パーティー気分で…残っていた焼き鳥などを適当に。
５月１日は、先に書いたように僕の仕事があったのでどこも出かけず。
５月２日は、長女・次女が歯医者に行かねばならなかったので、歯医者以外出かけず。
鎌倉の歯医者に行くのは、きっと道が大渋滞だろう、と恐怖でしかなかったのだが、案外空いていた。
でも、人混みはすごかった。
鎌倉だから、多くの人は車で来るのではなく、東京から電車で来るのだね、と行ってから気づいた。
以上、昨日分までの日記でした。
このほかに、隙間時間を見ながら仕事のプログラムをしていて新しい知見を得たので、次にそのことなど書く。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |