どんぶらアニマル さんぽ道

CBR250RR(MC22)とNSR80(HCO6)とAPE50(AC16)を中心とした備忘録。

幅広の革靴を探した結果、ビルケンシュトック パサデナのソール交換

会社がM&Aとかいろいろあって親会社からドレスコードの締め付けが厳しくなり、営業だろうが開発だろうが経理だろうが全員スーツに革靴、髪色も細かく限度が決められる事態に。もともと開発をやってて「格好で仕事してるんじゃない」とか言ってたけど、懇意にしている上司が怒られるという望まない結果になりそうで、仕方なく適当な革靴を買って履いてる日々。。。

自分の足はかなり幅広なので、スニーカーはニューバランスの4Eがちょうどいい感じで、ABCマートなんかに行っても選択肢はあまり無い。革靴はもっと選択肢が無くて履ければ良いやと妥協して続けてきたけど、久々に幅広な革靴を探してネットサーフィンしてたらビルケンシュトックを目にして、なんかかわいい、これなら指先も余裕があっていいかもと試しに中古を落札してみた。

落札したのはパサディナで、履いてみると窮屈感が無くていい感じ。でも中古故、インソールはカチカチで履き続けてもなじむ気がしない。純正はすでに廃盤らしい。ということで試しに汎用のインソールに変えて見た。

 

用意するもの

  • インソール
  • ハサミ
  • (油性)ペン

 

使うインソール

インソールはアマゾンで買ったJINN TOKYOのインソール。理学士や医師監修とされるインソールが沢山あるけど本当かどうか。もう1つ、(今回は使わなかったけど)コロンブスの高反発抗菌インソールも買っておいた。ビルケンシュトックは全体的にかなり幅広なので、土踏まずのところが細くなっていないこと、つま先付近も細くなってないものを選んだ。他のインソールと比べて比較的つま先が細くなってないものもビルケンシュトックには細く見えたので、32cmまで対応する大きなものを選んで切って使う前提で買った。

 

今回使うのはJINN TOKYO。表はこんな感じ。インソールを変えたらビルケンシュトックの意味が無いと怒られそうだけど。

BIRKENSTOCKのインソール交換

 

BIRKENSTOCKのインソール交換

 

パッケージにはこんな説明が。3980円となってるけどアマゾンでは980円だった。

BIRKENSTOCKのソール交換

 

型取り

さて、ビルケンシュトックのサイズをカバーできる大きさがあるのか?

ビルケンシュトックのインソール交換

オリジナルは縁の部分の上の方が広がってるので真上から見るとJINN TOKYOの方が小さく見えるが底の部分はほぼ同じだった。

BIRKENSTOCKのインソールのサイズ比較

つま先部分をカットするだけでうまくいく気がしてきた。

ちなみに、オリジナルのインソールを取ろうとしてもびくともしなかったので接着されているのかと思ってたけど、ぐいぐい引っ張ると取れた。でも慎重にやらないと薄くなってる縁の部分が割れそうなので要注意かも。

 

カット

まずは右足から、2つのソールを重ねてマジックで線を引く。が、写真では線が見えないなぁ。ちいさく切ってしまうと後戻りできないので気持ち2mm位大きめに切る感じで線を引いてみた。

ビルケンシュトックのソールをカット

 

うっすらとマジックの跡があるので、これに沿ってハサミでカットする。

BIRKENSTOCKのインソール交換

 

こんな感じにカットした。

BIRKENSTOCKのソールをカット

 

左足分はカットした右足のソールを重ねて型取りをして右同様にハサミでカットする。

ビルケンシュトックのインソールを切る

 

フィッテング

自分の足にではなく、パサデナにインソールをフィッティング。なんと右足は一発でピッタリ。左足は少し大きかったので2mmほどつま先をカットしたらぴったりに。

ビルケンシュトックのインソールを交換した

インソールが変わるとビルケンシュトックらしくない感が強い。。。

ビルケンシュトック好きな人から見ると許せない魔改造なんだろうな。

いっそのことソールに動物の絵でも描いてやろうか。

 

でも完成。

 

試着

衝撃吸収なインソールなので、カチカチのインソールとは比べ物にならないくらい楽で気持ちい。底面から足の裏までの距離はオリジナルと大きくは変わってない感じだけどちょっと余裕が大きくなった何時がする。

ビルケンシュトック本来の良さは無くなってるんだろうけど、これは良いかも。母指球あたりの左右の幅の余裕がありすぎな感じがするけど、しばらくこれで歩いてみて必要に応じてインソールの厚みを追加したりしてみようと思う。

普通の靴屋にも幅広タイプの革靴があるんだけど、幅広対応の靴でもワンサイズ大きいものでないと親指か小指の付け根の上のあたりが痛くなるので、体に対して靴がでかいという違和感が。更にとんがってる靴が多いけどこれはもう靴人間に見えるくらいに靴の存在感がでかい気がして嫌だった。

ビルケンシュトックも幅が広いので存在感はあるんだけど、堅苦しくない感じのシルエットとデッキシューズのようなデザインが好印象だった。残念なことに、丸っこいデザインは新品では買えないらしい。でもビルケンシュトックは気に入ったのでモンタナ、シカゴ、ギルフォードとかも試してみたいなぁ、と思ったり。これも先が広くて丸っこいのは古いモデルじゃないと無いのかなぁ?

ちなみに落札後、ごみを落として、コロンブスのレザーキュア 除菌・抗菌ミストで念入りに除菌して、革ジャン用のオイルを塗るという基本手順は済ましといた。靴ひもは手もみで洗ったら真っ黒な汁が出た挙句デコボコになったので長さ60cm、太さ3.5mmの汎用靴紐を買って交換した。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




DDNS Nowの自動更にDiCEを使ってきたけど正常に更新されなくなった

DDNSにDDNS Nowを使っていて、自動更新にはDiCEを使ってきた。が、数日前から外部からのドメイン名によるアクセスが不通になっていた。

 

原因調査

DiCEの手動での更新を実行して1日待ったがアクセスできるようにはならず。

DiCEを手動実行

 

長くても24時間で反映されるはずが、24時間待ってもアクセスができない。こんなに時間がかかるのもおかしいと思い、ちょっと調べてみたら、DiCEが認識しているグローバルIP(赤枠の部分)がおかしい。ルータが示しているグローバルIPのアドレスや自分のネットワークのグローバルIPを調べるサイトで得られるアドレスと違っている。

DiCEでDDNS Nowの自動更新


DiCEを再起動したり再インストールしたりしたが変わらず。グローバルIPが引けないとこのブログもまともに表示されないなど、いくつか困ったことになるので、これ以上DiCEにこだわるのは中止した。

 

解決

他の方法を考えたり、調べたりしていたら、DDNS Nowにcronでの実行方法が書かれていたので、これを試してみる。まずはcronに登録する前にコマンドラインで実実行してみた。(オレンジの部分は環境に合わせて変更する)

curl -X POST -d 'domain=hogehoge&password=hagehage' https://mogemoge/update.php

あっけなく実行して1分後には外部からアクセスできるようになった。

 

そこで下記コマンドを実行してcrontabのエディタを開き、

sudo crontab -e

下記の1行を追加した。

0-59 * * * * curl -X POST -d 'domain=hogehoge&password=hagehage' https://mogemoge/update.php

 

エディタをバックグラウンドに落とさす、ちゃんと終了させて登録されたか確認。

hoge@cf-n10:~$ sudo crontab -l
[sudo] hogeのパスワード:
(中略)
0-59 * * * * curl -X POST -d 'domain=hogehoge&password=hagehage' https://mogemoge/update.php

 

反省とか

異常発生が(多分)1/19の20時頃で、気付いたのがその日の22時頃、復旧したのが1/20の23時頃と気付くのにもちょっと遅れたし、手間を惜しんでDiCEの更新が反映されるのを期待して待ちすぎてしまった。

DiCEがうまく機能しない原因が分からずcronに移行することになったけど、個人的にはこっちの方が安心。Windowsマシンはクライアント専用であって24時間動かすとは限らないけど、Linuxマシンは他のサーバを動かしたりしてるから電源を落とすことは無いから。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




crontabに書いた設定が反映されない

crontabに書いた設定が反映されずに小一時間悩んでしまった。結論は「crontab -e」で開いたエディタは編集後にバックグラウンド落とさず終了させること。

環境

OS:Ubuntu 22.04.1 LTS(確認コマンド:lsb_release -a)

 

crontabに書いたエントリが反映されなかった原因

「sudo crontab -e」でrootのcrontabを編集後、「sudo crontab -l」で設定を確認しても追加したエントリが表示されず認識されていない。

cronを再起動したり、設定を再読み込みしたりしたけどダメ。

  • sudo systemctl restart cron
  • sudo systemctl stop cron
  • sudo systemctl start cron
  • sudo /etc/rc.d/init.d/crond reload
  • sudo /etc/init.d/cron  restart

等を試すも「sudo crontab -l」の結果は変わらず。これまでこんな現象にあったことないのに。

でいろいろ考えた末にやっと気付いたのが、いつもemacsでソースの編集などをやってて、編集と実行を1つのターミナルで繰り返すことが多いので、編集したらemacsを終了せず、Ctrl-Zでバックグラウンドに落として、プログラムの動作確認後にfgでフォアグラウンドに戻して編集を再開するという運用をしている。今回のcrontab -eでも同じ事をやってたのが原因だった。ファイルを保存してもemacsをバックグラウンドに落とすと設定は反映されず、emacsを終了すると

crontab: installing new crontab

とメッセージが出て、「sudo crontab -l」で追加したエントリが陣指揮されていることが確認できた。多分、vi等の他のエディタでも同じなのではないだろうか?

 

emacs終了時の様子。ファイルを保存しただけではこの「crontab: installing new crontab」のメッセージは出ない。

crontabの設定が反映されない原因

systemctl 等によるreloadやrestartは不要だった。reloadかrestartが必要なケースはディストリビューションやバージョンの差なのかもしれないので、「sudo crontab -l」で認識しているにも関わらず、時間になっても実行されない場合は(実行エラーが発生していないか確認するとともに)reloadかrestartをやってみるといいかも。

 

解決方法

crontab -eで起動したエディタをバックグラウンドに落とすといくら編集内容を保存しても反映されない。なのでエディタはマメに終了すること。

 

cronの反映の基本

変更が反映されずにinitやsystemctlでやみくもにcronの再起動をやってたけど、初心に却って整理してみる。

昔々、kernel 0.9の時代のslackwareを使ってた頃は/etc/inittabをエディタで直接編集して、initでcronを再起動させてた。その後、いつの頃からかcrontab -eで設定変更するようになってからcronの再起動が必要なのか否かあいまいなまま今に至る。

cronの制御がinitからserviceに変わりsystemdに変わっていったことも絡むので調べるのが面倒で、httpdやsmbd等もそれぞれの方法で試して動くものを使ってた。

 

で、制御方式が何であろうとcrontab -eで編集した場合、cronの再起動や再読み込みは必要なさそう。少なくともubuntu 22.04では。

crontab -eで設定を行うと、/var/spool/cron/crontabs/の下にユーザ名のファイルができる。rootで作った中身を見てみるとcrontab -eで編集した内容が書かれてる。(前の例から実行周期を変えたりエントリを追加したりしてるので内容が変わってます)

crontab -eで設定を反映

 

cronの再起動なくして反映されるか否かはcrontab -eの仕様にあるんじゃないかとターミナルでman crontabを実行したけど日本語のmanが表示されなかったのでdebianの日本語man pageを参照した。


この中に下記の記述があり、cronの再起動は必要ないと書かれてる。

さらに cron は 1 分ごとにスプールディレクトリ(または /etc/crontab ファイル)の最終修正時刻(modtime)をチェックし、もし変更されていれば、 すべての crontab ファイルの最終修正時刻をチェックし、 変更された crontab ファイルを読み直す。 よって crontab ファイルを修正するたびに cron を再起動する必要はない。

ただ、この説明だとcrontab -eを使わずに直接編集してもタイムスタンプが更新されれば反映されるはずで、元々の問題のcrontab -eをバックグラウンドにしても反映されるんじゃないかと思われるんだけどどゆこと?

 

以前に設定の記述を間違えてた時、動かないなぁと設定の変更をするとともに反映されてないのかもと再起動や再読み込みを一緒に実行してしまい、正しい設定ができた時にも再起動をしたことで反映されたと勘違いしたことがあった。もしかしたらWebサイトで再起動が必要と書かれているものの中にも同じような経験から書かれているものがあるのかもと思ったり思わなかったり。。。

 

Linuxのサービス/デーモンの制御

cronの設定の反映は別として、cronやsamba、apache等のサービス/デーモンの制御のお作法はどうあるべきななんだろう。

で、まさしく自分の状況だと思ったのが下記の解説。とても分かりやすくて感謝。

現時点では、サービス/デーモンによってはinit、service、systemdのどれでも動くようになってるというところがと真実への探求のとっつきにくさになってる気がする。どれが使えるかはスクリプトが用意されているか否かによるのでディストリビューションのバージョンにも依存する。ubuntu 12.04まではinitだけで全部できてたけどubuntu 14.04からsamba等がserviceでないと動かなくなってたので、どれでも動くようになったのはどこからなんだろ?initのスクリプトだけなかったのかなぁ。

 

更に、initのスクリプトがあればOS起動時に自動的にsystemdのスクリプトに変換してくれる仕組みもあるみたい。

 

イマイチすっきりしないけど整理する糸口は掴めた気がするので今日はここまで。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




CBR250RR(MC22)のプラグ交換の準備と下調べ

エンジンがかからない問題で発注してあったプラグがやってきたので見てみたところで?となった。右が今回発注したMC22対応品のDENSO IUH27。左は車用。ネジ径の違いは置いといて、車用はガスケットから下が全ネジになってるのに対し、IUH27は5mm位ネジ山が無く、外径が太くなってる。エンジンがかからない問題で抜いたプラグもこんな感じになってた。

CBR250RR(MC22)のプラグ

 

これまで車のエンジンしか見てこなかったけど、どれもシリンダーヘッドの上面一杯までネジが切られてて、IUH27のようなネジが切られていない部分があるとネジ山を壊しながら入っていくことになるので気になって調べてみた。

後日の実際のプラグ交換はこちら

 

プラグ穴の構造確認とネジ山が無い部分の深さの測定

予備のMC22のエンジンがあるので、こいつでネジ穴の部分がどうなっているのか見てみた。プラグホールが深くて肉眼ではよくわからなかったので昔aliexpressで600円で買ったスマホでも使えるUSBカメラを使った。

エンジンの中を覗くカメラ

 

まずは(ほぼ)真上からの図。

バイクエンジンのプラグホール

プラグのガスケット(座金)が当たる部分が少し窪んで、その先にネジ山より太くてネジ山のない部分があって、その先にネジ山がある。

分かりにくいので角度を変えて見てみた。不鮮明だけどIUH27のネジ山が無い部分が収まる部分(黒く見える部分)の下に穴が細くなってネジ山が見える。なるほど、こんな作りになってるんだ。

バイクのエンジンのプラグホールのネジ山

 

ネジ山のない部分の深さを測ってみた。

バイクのエンジンのプラグホールのネジ山のない部分の深さ

 

8.8mm位。ノギスのボディが大きいのでプラグのガスケット(座金)が当たる部分からではなく一段高いところからの値なので8.0mm位が実際の深さになりそう。

バイクのエンジンのプラグ穴の深さ

プラグのネジ山が無い部分の長さの測定

今度はプラグ側を測ってみる。

バイクのプラグのネジ山のない部分の長さ

だいたい4.4mm位。ねじ込んだときにプラグのガスケット(座金)がつぶれる分も考慮すると5.5mmから6.0mm位がヘッド内に入っていくと思われる。

ヘッド側の深さが8.0mm位で、入っていくプラグ側のネジ山のない部分の長さが6.0mmだとして2mm位の余裕があることが分かったので、安心してIUH27に交換できる。バイクのエンジンってみんなこうなってるのかな?何か規格があるんだろうけど。

何にしても適合表等でバイクに合わせて選んだ方が安心。今回はNAPSの適合表でIUH27がMC22に適合していることを確認しておいたので心配する必要はなかったんだけど、なにせこんなプラグを見たのは初めてなもので気になって。。。

 

プラグの準備

プラグ交換が面倒な車両でターミナルナットを外し忘れてエンジンに装着するとショックが大きいので、忘れないように今のうちに外しておく。

プラグのターミナルナットを外す

ターミナルはネジになってるので、普通にナットを外すように半時計方向に回せば外れる。新品なら指で回せる。中古だと指では回らないこともあるけど、ナットを再利用する場合はナットを傷付けたり変形させないないように注意しつつ、ガムテや厚保紙等をナットに撒いてペンチとかで掴んで回す。

 

MC22のプラグ交換に使う工具

右のソケットがエンジンがかからない問題で使った何故持ってるのか不明な謎ソケット  MC22純正プラグレンチ(89216-KT7-000で2021年9月にmonotaroから849円で買ってた履歴を発見。すっかり忘れてた)。左が今回アマゾンで見つけた799円のKALOLINNA スパークプラグレンチ 16mm不明な謎ソケット純正は全長が長くて、プラグホールに居れたり出したりするときに上部がつっかえてスムーズにできなかった。アマゾンで買ったやつは全長が短いことと、首振りになってることでプラグホールからの出し入れが楽になるかもと期待して購入。

CBR250RR(MC22)のプラグ交換にソケット

 

プラグを入れてみるとこんな感じ。マグネットはかなり強力なので落ちることは無さそう。

CBR250RR(MC22)のプラグ交換用ソケット

 

ラチェットを使うと、ラチェットのヘッドが大きいことが足かせになるかもしれない。その点、不明な謎ソケット純正プラグレンチは長い反面本体はスリムでメガネで回せることから狭いスペースには入れやすい。

CBR250RR(MC22)のプラグ交換に使う工具

 

それぞれ、プラグを締め込んだ状態でのヘッドカバーからの飛び出し具合はこれくらい。

CBR250RR(MC22)のプラグ交換用ソケット

CBR250RR(MC22)のプラグ交換用ソケット

 

なかなか時間が取れないのでプラグ交換はのびのびになってるけど早く交換したい。

2024/02/20 追記

プラグを交換した。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




CBR250RR(MC22)で東京駅へ

1/3の23:00にぷらっと家を出て久々に東京駅へ。通常のこの時間の所要時間は40分位。家を出たときは行き先を決めてなかくて、遠回りしてしまったので東京駅に着いたのは24:30頃になった。いつもは深夜でも散歩やジョギングしている人や友達と集まっている若者がいたりする行幸通りだけど、小雨だったこともあって今日は1人もいなかった。雨は関係なくて時期の問題なのかも。

CBR250RR(MC22)で東京駅

行幸通りはあまりに幅が広いので広場みたい。

 

皇居方面はこんな感じで、皇居までずっと続いてる。

CBR250RR(MC22)で行幸通り

バイクの乗り入れはNGなので通りでエンジン切って押して入る。誰もいないんだけど。。。

 

この時間は、日中の渋滞が嘘のようにスイスイ走れる。皇居の周りをまわってみたり、霞が関の官庁街を探検したり、日中では行こうと思わないルートを思うがままに走れる。車がほとんどいないし、道が太いので道を間違えても簡単にリカバリできる。靖国神社の参道は深夜も解放されているので歩き放題。

今日は、小雨だったので探検しないでまっすぐ帰った。ルートはこんな感じ。皇居付近をグルグル回ってるのは、以前に来た時の皇居付近の休憩ポイントを探してたから。東京駅付近をチョロチョロしてるのはコーヒーが欲しくてコンビニを探してたから。

CBR250RR(MC22)で皇居周辺をツーリング

まあ、普通の人はこんな時間にこんなところには行かないだろうけど。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




初詣叶わず、モヤイ像が変なことになってた。

娘が14:00まで高田馬場でダンスの練習だったので、高田馬場で待ち合わせして帰りに明治神宮に初詣をと高田馬場から寄り道しつつ原宿まで。

 

新宿で娘の靴を探してぶらぶらしてから原宿へ。とりあえず竹下通りへ。普段の週末よりは人が少ない。みんな帰省しちゃってるから?

正月の竹下通り

 

娘はNIKEショップで見つけたジャージに心奪われてしまってた。学校指定のジャージと違ってむっちゃ高かった。結局、娘はNIKEの袋を持ってる。そして表参道へ。正月の表参道

 

表参道の竹下通り側の歩道は的屋がびっしり。

正月の表参道の的屋

 

一蘭は歩道まで行列が。

正月の表参道の一蘭

 

ちょっと戻って新しくなったラフォーレ原宿へ。入ってすぐに20:00の閉店時間となってしまってあまり物色できかった。

正月のラフォーレ原宿

 

表参道のラフォーレ付近の交差点に一部が切り取られたような変な形の新しいビルが。

東急プラザ原宿「ハラカド」

 

ラフォーレの韓国系ショップの近くの謎な自販機。何が出るかわからないうえ、飲むのも勇気がいるのでスルー。

ラフォーレ原宿の謎自販機

 

お腹がすいたので的屋で適当に腹を満たして、

表参道の的屋

 

いざ、明治神宮へ!

正月の明治神宮。閉まってる。

閉まってる!これまでの人生で正月に神社やお寺が閉まってる事態に遭遇したことがなかったので閉まるとは思ってもなかった。正月に明治神宮に来たのは初めてで、明治神宮の公式サイトで調べてみると1/2は18:00閉門だった。

 

仕方ないので家路を目指しつつ、一旦、渋谷のドン・キホーテへ。近年の渋谷駅の中は毎回迷子になる。ハチ公口に出でたかったのにモヤイ像近くに出てしまった。で、遠目にモヤイ像が見えてきたんだけどなんかピンクで変な感じになってる。

渋谷のモヤイ像がアーニャになってる

しばらくなんだかわからないかったけど、娘が気付いた。よく見るとアーニャのツノ的な髪飾りが付いてるんでアーニャだと。まじか。。。

 

なんとか渋ドンに着いて、娘がカラコン買って今日のミッションは完了。

渋谷ドン・キホーテ

 

初詣はいつになることか。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




CBR250RR(MC22)でどうし道から山中湖へ

昨日というか、今朝方までエンジンがかからなかったことは忘れて、久々のぼっちツーリング。マスツーはやってると言う分けでなく、いつもぼっち。今日も出遅れて出発は14:00頃。天気が良くて平地は暑かったけど、宮ケ瀬あたりからちょうどいい冬の感じの気温に。山中湖付近に着くと富士山が綺麗に見えた。真っ白ではないけど雪化粧。

CBR250RR(MC22)でぼっちツーリング

 

今日の目的は、山中湖が凍ってるか確認すること。凍ると氷上に人が乗っかってるのを見かけたポイントに行ってみたけどまだ凍ってなかった。もう日が落ちてしまった。

CBR250RR(MC22)で山中湖

 

CBR250RR(MC22)で山中湖ツーリング

 

なんとなくバイクを止めたところは(その時は暗くてわからなかったんだけど、帰って調べてみたら)山中湖村のシアターひびきと言う施設の駐車場だったみたいで、近くの自販機でコーヒーを買って飲んでいたところ、どこかからジャバジャバと水の流れる音が聞こえてくる。音の元に行ってみると変わったポンプがあった。

CBR250RR(MC22)で山中湖村

 

凍ってたらどうというわけではないけど、今年の2月に初めて見て「おお!」と思ったのでまた見たくて。2月(2/4)に見たのはこんな感じ。

山中湖の氷

 

山中湖の氷結

 

今日の経路はこんな感じ。いつもは246の(なんだかゴロのいい)妻田そりだ交差点から山に入っていくことが多いんだけど、すいているSSがなかなか無くて246をずいぶん先まで進んでしまったので宮ケ瀬まであまり通らないルートになった。

CBR250RR(MC22)で山中湖ツーリング経路

 

最近は通勤ばかりで乗ってたからタイヤの真ん中が平たくなってきた。

CBR250RR(MC22)のタイヤの減り

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




CBR250RR(MC22)のエンジンがかからない。。。

仕事とか自治会とかでなかなか乗れず、1か月ぶりにCBRで出かけようとしたらエンジンかからず。下り坂を利用して何とかしようとしたけどダメだった。登り坂がきつくて家まで押して帰るのももう無理。現地で何とかするしかない。。。

 

はじまりは

久々に時間が取れたので軽くひとっ走りしようと23:00頃、いつものようにマンションの前の道までエンジンをかけずにCBRを出して、セルを回すも非常に力ないポッという燃焼音が1気筒だけで起こってて他はだんまりな感じだった。5分位試していたらバッテリが弱って来たこともあり、下り坂を使えばかかるでしょ!と思って、3速に入れて勢い付いたところでクラッチを繋ぐもかからず。3回ほど試したところで坂が終わってしまった。

300m程平地を押すとまた下りがあるのでそこまで押していった。その間も勢い付けてクラッチを繋ぐもかかる気配もない。年の瀬のこの季節なのに、もうこの時点で全身汗だくでビショビショ、そして運動不足もたたって酸欠で15分位動けなくなった。なんとか下り坂に着いて4回ほど試すもかからず。ここはこのあたりの一番低い場所でもう下り坂は無い。そして家までは登り続きで押して帰るのはムリとなってしまった。

23:30を過ぎてる。。。

 

第一ラウンド(バッテリブースタ投入)

押しがけはもう無理なのでかみさんの車を借りて動員。酸欠が収まらず、家でしばし休憩して24:00にかみさんの車に昔買ったバッテリブースタを載せてあったことを確認して、車で現場に向かった。車のエンジンをかけたまま、ケーブルを繋いでセルを回すもかかる気配なし。

CBR250RR(MC22)のエンジンがかからない

バイクにバッテリーブースターケーブルを繋ぐ

ポッと小さな燃焼音がしているのが1気筒だけなのか、2、3気筒あるのか知りたくてサイドカウルを外してエキパイを触ってみた。1番だけほんのり温かく、他は冷たかった。下り坂で試してるときにスロットルを開けたりしてたからかぶってしまったか?乾くまで回すか、プラグを抜くか悩むもこいつのプラグを外すのはとても面倒なので回す選択をして、スロットルは一切開かず、チョークも引かずにセルを回す。

ただ、ここで疑問が。チョークを引かないとポッすら聞こえず、まったく燃えてない感じの音になる。かぶってるならチョークを引いたら燃料が濃くなってもっと悪化するはずが逆の現象が起こってるような気がする。CBRはレバーにCHOKEと書いてあるけど実際はバイスタータだから確実に燃料がドボドボと入ってしまう気がする。

 

30分ほど試しても全く状況が変わらず、深夜にセルの音を響き渡らせるのは近所迷惑なので人家のないところへ押して移動する。

 

第二ラウンド(プラグ磨きと電気系確認)

深夜1:30である。目的地の人気なのないとこまでCBRを押して行く。目的地は1mくらいの高低差がある低い場所で、そこに持ち込んだら尚更戻れなくなるので、CBRは路肩に置いて先に車を目的地まで持っていて作業に適してるか下見。

CBR250RR(MC22)を路肩に放置

 

車で目的地に行き、近所に人家が無く、通行の邪魔にもならなそうなことを確認して、途中に放置してきたCBRも持ってきた。

CBR250RR(MC22)をバッテリブースタに繋ぐ

バイクにバッテリーブースターケーブルを繋ぐ

セルを回し続けても全く状況が変わる気がしなくなってきたので、渋々プラグを見てみることにした。

まずはアクセスしやすい4番シリンダー。CBRのプラグを外すのは多分初めて。使えそうな工具を探すとこんなのが出てきた。

CBR250RR(MC22)のプラグ交換

 

こんな感じでスパナで回す。

CBR250RR(MC22)のプラグ交換

 

抜けたプラグはこんな感じで、予想外にカッサカサに乾いてた。第一ラウンドで現象的に燃料でかぶってる気がしないと思ってたのは当たってた。

CBR250RR(MC22)のプラグの焼け具合

そしてカーボンで接地電極が真っ黒け。中心電極のエッジが白っぽいので燃料でかぶってるどころか燃料が足りないような燃え方をしているのかも。燃料じゃなくて長く乗ってなかったのでカーボンでかぶってたと思われる。これみて、チョーク(バイスタータ)、スロットル共にいくら開けても大丈夫と判断できた(多分)。

取り合えず、ワイヤブラシで磨いた。接地電極は黒いままだけど堆積していたカーボンだけは取れたのでとりあえず良しとした。

CBR250RR(MC22)のプラグ磨き

 

念のため、プラグキャップまで高圧が来てるか確認しといた。とりあえず来てた。

CBR250RR(MC22)のスパーク確認

エンジンに必要な基本条件の1つ「良い火花」はクリア。ここで「良い混合気」の前提の燃料がキャブに来てるか確認するところだけど、満タンのタンクを下ろしたくないのとマフラーの出口からガソリン臭がしてるので燃料は来てるので良しということにしといた。良い混合気になってるかには疑惑が残る。残る「良い圧縮」を測るにはコンプレッションゲージが必要なんだけど行方不明なことと、エンジンがかからなくなるほど複数のシリンダーの圧縮が同時に悪くなる気がしないので圧縮にも問題ないだろうということにしといた。何の問題もないときは、4気筒中2気筒のプラグコードを抜いてもアイドリングはせずともスロットルを開け気味にしたらエンジンはかかってたし。。。

 

プラグを装着してチョーク(バイスタータ)を引いてスロットルはオフでセルを回すと2気筒っぽい音でエンジンがかかった。が、2気筒ではアイドリングせずスロットルを開かないと回転を維持できない。スロットルから手を離すと即止まる。エンジンがかかった時の音はこんな感じ。開けといたスロットルから手を放したら止まった。

この後、エキパイを触ってみると、3番と4番が熱くなっていて、1番はほんのり温かく、2番は冷たかった。3回くらいかかったのでゴールは近いと思って、缶コーヒーで一服して再トライすると全くかからなくなった。。。一服しなければよかった。

プラグが原因であろうことは分かってきたので、新しいプラグを買ってきて交換する選択もあったんだけど、明日(すでに今日?)は大晦日目前。欲しいプラグが買えるお店が開いてるかも分からないし、買ってくるまで路肩に放置することになる。多分、帰ってお店が開くまで仮眠を取ったら昼まで寝てしまいそうな予感。なのでこのまま続けることにした。

で、仕方ないので、左のサイドカウルも外して1番のプラグを抜いてみた。濡れて光ってるように見えるけど実際はカラッカラでカーボンまみれ。こいつも磨いて再装着。

CBR250RR(MC22)のプラグの焼け具合

 

ついでなので1番の電気系も問題ないことを確認。ずいぶんと元気な感じ。

CBR250RR(MC22)の点火系の確認

 

で、何やっても燃料でかぶるということは無いであろうと、非常に力ないポッという火が付きそうな音が増えるようにチョーク(バイスタータ)、スロットルを色んな開度で試してみた。

チョークを引いてないと、スロットルがどうであろうとポッが全く起きない。チョークを目いっぱい引いて、スロットルを5mm~10mmひねってたあたりでゆっくり動かしてると爆発回数が増える開度がある。20秒位セルを回してダメだったら15秒休憩してを繰り返してたら、20分後くらいにいきなり一気に4気筒全部が燃焼して吹けふけ上がった!やったぁ!もう3:45。

 

考察とか

今回分かった(と思う)こと。

  • 始動時、チョーク(バイスタータ)、スロットルの開け具合でかぶることは無い。(自分の車両に限るかも)
  • 1か月放置したことで、プラグのカーボンがどうにかなってスパークが飛びにくい状態になってた。

かぶる心配については、NコロのCVキャブは加速ポンプが付いていて、アクセルをオフから開くたびにピュッピュッと燃料が送り込まれてたので、CBRでもスロットルオンで同じように燃料が送られるイメージをしてたけど、CBRのキャブをオーバーホールした時を思い出すとそんな仕組みは無かったのでCBRでスロットルを開いてかぶるというのは幻想だった(と思う)。逆にエアが増え、流速が下がるからメイン、スロージェットからの燃料分は薄くなるはず(と思う)。だから始動時はスロットルオフにしてバイスタータを使って燃料を増やしてやるというのがCBRなんだろな(と思う)。でも走行中にガバ開けした時の加速ポンプ代わりに燃料を増やす仕組みってどうなてるんだろ?

プラグのカーボンについては、今後は予備プラグとプラグソケットを積んどいた方が良いのか?近年はバッテリが弱ったときのグッズとしてバッテリ式のジャンプスタータが一般化してるけど、ここまでかからないとそんなものでは無理っぽい。

前の持ち主から1年位しか所有してなくてプラグ交換したと聞いてたので、まだまだ交換時期ではないだろうと思ってたけど、見た感じも交換した方が良さそうなので発注しといた。夏にもたまに始動まで1、2分かかることがあったのもプラグが原因なのかも。この症状が出るのはいつも通勤の帰りの始動のときだったので、朝の通勤渋滞が関係してると思われる。

これまでは、2、3日に一回は乗ってて、乗らない期間は長くても1週間でだった。1か月も乗らないとダメになるほどプラグは終わってたのかも。通勤の朝の渋滞もプラグには良くなかったかも。とか思ったり。

CBR250RR(MC22)のプラグの状態

 

ひとっ走りしようと家を出たのが23:00頃で、エンジンがかからず30分位下りや平地で押しがけしたりして汗だく、冬なのにパンツもビチョビチョになって酸欠になって動けなくなった。バイクを置いて家に帰り、30分ほど休憩して車でバッテリブースタケーブルを持ってバイクのおいてあるとこまで行ったので24:00頃。そこからプラグを磨いたりなんだかんだでエンジンがかかったのが3:45頃。CBRでひとっ走りして4:30。現場に放置してきた車を取りに行ったり片付けしたりで5:00。

この年になって路肩で何時間も修理的な事をするとは思ってなかったけど、20代の頃にNコロで苦難を楽しんでた時の匂いや感覚を思い出して懐かしく感じた。今日も楽しかった。でもなんか疲れた。

結局、コンビニに行くのも忘れて気持ち良く走ったら帰宅してしまった。そもそも何しにコンビニ行こうと思ってたかも忘れた。

 

後日

翌日、山中湖から戻って気付いた。左右のサイドカウル同士を繋ぐボルトを締めた記憶が無いと。で、格闘していた現場に戻ってみるとあった。

CBR250RR(MC22)のカウルボルト

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




JavaScriptで巨大なMySQLのテーブルを仮想スクロールでサクサクと表示、スクロールさせたい

MySQLに入ってる140列、10万行の巨大なテーブルの分析をするUIを作りたくて、普通にHTMLのテーブルを作ってみたらいつまでも表示が完了しなかった。試しにもっと小さい11列、6000行を表示してみたら表示完了まで1分40秒、メモリの使用量は1.5GByteになり、重すぎてスクロールはまともに動かなかった。8000行に増やすと5分待っても表示されず、3GByte以上使っていた。

そこで仮想スクロールを簡単に実現できるライブラリを探して試してみた。

要件

ライブラリに求める要件は以下の通り。

  1. node.jsの様なプラットフォームは使わず、JavaScriptのみで使えること
  2. dbは日々大きくなるので140列、20万行が扱えること
  3. 上下左右のスクロール時に、ヘッダを固定できること
  4. 列名やセルのクリックイベントを取れること
  5. セル(列)の色を変えられること

 

環境

サーバ側

  • OS:Ubuntu 22.04.1 LTS(確認コマンド:lsb_release -a)
  • apache:Apache/2.4.55 (Ubuntu)(確認コマンド:apache2 -V)
  • python:3.10.12(確認コマンド:python -V)
  • CPU:i5-2520M CPU @ 2.50GHz 4core(確認コマンド:cat /proc/cpuinfo)
  • メモリ:8GByte

クライアント側

  • OS:Windows10 Pro
  • CPU: E3-1280 v3 @ 3.60GHz 4core
  • メモリ:24GByte
  • ブラウザ:chrome 120.0.6099.111(Official Build) (64 ビット)
  • ブラウザ:brave バージョン: 1.61.101 Chromium: 120.0.6099.71(Official Build) (64 ビット)

 

ライブラリの一次選定

仮想スクロールのライブラリは沢山あるみたいで、評判の良さげなcheetah-gridを試してみたが、サンプルをサクッと動かせずさっさとあきらめた。

次に良さげに見えたのがSlickGrid。これはサンプルも簡単に動かせて、いろんなバリエーションの簡潔なサンプルが沢山あるのも良かった。サンプルの巨大なテーブルもサクサク動いてる。要件の1(node.jsとか使わずJavaScriptのみで動く)は満たしてるっぽいので、その他の要件も満たせるか試してみることにした。

 

サンプルを動かす

サンプルを試す方法は2つある。

1つは用意されたgithubのexsamples。ブラウザからそのまま動かせるのはありがたく、ここのUsing a filtered data view to drive the gridが6列、5万行でサクサク動くので評価に前向きになった。

もう1つは、git cloneしてローカルに設置して試す方法。

どっちも同じサンプルを動かせる。ローカルに置けば、ちょっとコードを変更して試すことができるので、要件を満たせるか試すには適してる。

ローカルで簡単に動かすには、apacheのDocumetRootの配下のフォルダでgit cloneして、

ブラウザから下記URLにアクセスするとgithubのExsamplesと同様のサンプルページにアクセスできる。

http://<サーバIP>/<展開したフォルダパス>/SlickGrid/examples/

 

要件を確認する

サンプルのBasic use with minimal configurationを使って、

  • 20万行の動作確認
  • スクロール時の左端のセルの固定

を試してみる。

簡単に動かしたかったので列数は変更せず、行数だけ増やしてみた。列数は要件よりかなり少ない(6列)けど、20万件は体感で500ms位で表示され、スクロールにストレスもない。10万件だと体感で100ms位で表示される。

左端のセルの固定も問題ない。評価する気が増してきた。

変更したスクリプト部のコードはこんな感じ。

<script>
  var grid;
  var columns = [
    {id: "title", name: "Title", field: "title"},
    {id: "duration", name: "Duration", field: "duration"},
    {id: "%", name: "% Complete", field: "percentComplete", width: 90 },
    {id: "start", name: "Start", field: "start"},
    {id: "finish", name: "Finish", field: "finish"},
    {id: "effort-driven", name: "Effort Driven", field: "effortDriven", width: 90 }
  ];   var options = {
    enableCellNavigation: true,
    enableColumnReorder: false,
    frozenColumn: 0 // 2023/12/21 siba add
  };   var data = [];
  // for (var i = 0; i < 500; i++) {
  // for (var i = 0; i < 1000000; i++) { // 2023/12/21 siba mod 500 to 1000,000.
  for (var i = 0; i < 2000000; i++) { // 2023/12/21 siba mod 500 to 2000,000.
    data[i] = {
      title: "Task " + i,
      duration: "5 days",
      percentComplete: Math.round(Math.random() * 100),
      start: "01/01/2009",
      finish: "01/05/2009",
      effortDriven: (i % 5 == 0)
    };
  }   grid = new Slick.Grid("#myGrid", data, columns, options);
</script>  

frozenColumnが左端から何セル分を固定するかで、セルの番号-1を指定する。

forの部分で、もともと500行だったところを20万行に変えた。

 

本番の環境作りを想定して、サンプルから独立した環境を作って要件通りのモックを作ってみる。新たに/var/www/html/test_table_slick2フォルダを作って、この中に必要な一式を入れて動かす。ライブラリ類はlibsの中に入れる。

# フォルダを作成
mkdir /var/www/html/test_table_slick2
cd /var/www/html/test_table_slick2
mkdir libs
cd libs

# SlickGlidを取得
git clone https://github.com/6pac/SlickGrid.git

# Sortable.jsを取得
git clone https://github.com/SortableJS/Sortable.git

 

140列、20万行にして、コードがちょっと長いけどセルのクリックイベント等を盛り込んだHTML(test_table_slick-03b.html)を作った。

<!DOCTYPE html>
<!-- 参考:https://tokkan.net/javascript/slickGrid1.html -->
<html>
 <head>
  <meta charset="UTF-8">
  <title>SlickGrid test</title>
  <script src="./libs/Sortable/Sortable.min.js"></script>   <script src="./libs/SlickGrid/dist/browser/slick.core.js"></script>
  <script src="./libs/SlickGrid/dist/browser/slick.interactions.js"></script>
  <script src="./libs/SlickGrid/dist/browser/slick.grid.js"></script>   <link rel="stylesheet" href="./libs/SlickGrid/dist/styles/css/slick-alpine-theme.css" type="text/css" />
 </head>  <body>
  <div id="myGrid" class="slick-container" style="height:100vh;"></div>
  <script>
   var column_count = 140;
   // var row_count = 50000; // 2sec
   // var row_count = 100000; // 4sec
   var row_count = 200000; // 7sec    var columns = [];

   for (var i = 0; i < column_count; i++) {
     columns[columns.length] = { id: "title"+i.toString()+"", name: "Title"+i.toString()+"", field: "title"+i.toString()+"" }
   }
   // var options = {};
   var options = {
     // enableCellNavigation: true,
     // enableColumnReorder: false,
     frozenColumn: 0
   };
   var data = [];
   for (var i = 0; i < row_count; i++) {
     data[i] = {};
     for (var j = 0; j < column_count; j++) {
       if(j == 0){
         data[i]["title"+j.toString()] = "row " + i.toString();
       }
       else{
         data[i]["title"+j.toString()] = "abc" + j.toString();
       }
     }
   }    var grid = new Slick.Grid("#myGrid", data, columns, options);
   // 参考:http://ja.uwenku.com/question/p-fskbhkdn-cm.html
   grid.onDblClick.subscribe(function(e, args) {
     console.log('duble clicked: ');
     console.log(args);
     var item = args.grid.getData()[args.row];
     console.log(item);    });
   grid.onClick.subscribe(function(e, args) {
     console.log('clicked: ');
     console.log(args);
     var item = args.grid.getData()[args.row];
     console.log(item);    });
   // 参考:https://stackoverflow.com/questions/5703067/slickgrid-v2-0-column-name-id-does-not-follow-column-when-dragging
   grid.onClick.subscribe(function(e,args) {
     var allColumns=grid.getColumns();
     console.log(allColumns[args.cell].name);
   });   </script>
 </body>
</html>

column_count、row_countで列数、行数を変更できるようにしといた。以下のサイトを参考にさせて頂きました。

動かしてる様子はこんな感じ。クリックイベントはconsoleに出力する。

SlickGridで巨大なテーブルをスクロール

表示完了までの時間は、

  • 5万行:2秒
  • 10万行:4秒
  • 20万行:7秒

となった。10万や20万は常時使うわけではないので、この時間は許容範囲。

スクロールは20万行でもサクサクで問題ない。

 

セルのクリックイベントは課題が2つ見えた。

  • 最上段の列名のセルをクリックしてもイベントを捕捉できない。
  • ダブルクリック時は、クリックイベントも発火する。

ダブルクリックは使う予定が無いけど、定番のタイマーを使ってシングルクリックをキャンセルする等の処理をすれば良さそう。列名のセルのクリックイベントは、列名にボタン等を配置するプラグインがあるのでどうにかなるだろう。と思う。

 

セル、列、行の色の変更は試してないけど、サンプルを見るといろいろできそうなので、後で試すことにする。

 

表示までの時間の内訳

表示完了までの時間の殆どはデータ生成(本番だとデータの取得と加工)であって、表示時間自体にはあまりデータ量に依存しないのでは?と思ったので内訳をみてみた。

SlickGridの処理時間の測定

これは、chromeのdevtoolsのperformanceを使って、記録開始→CTRL+F5で再読み込み→表示完了で記録停止をして取ったデータ。

手描きの青線が全体の処理をやってる期間で、赤丸の中の紫のバーがSlickGridの処理。SlickGridの処理時間は164.21msとなってた。やっぱりデータ生成が支配的なのでSlickGridの性能は問題ではなく、高速化するならデータ生成を効率化するべきという感じの結果になった。

念のため、「var grid = new Slick.Grid("#myGrid", data, columns, options);」以下のスクリプトをコメントアウトしてSlickGridの処理を全て削除してみたけど、やっぱり表示完了まで7秒かかった。

本番では、MySQLに入ってるデータを使うので、サーバ側でのデータの読み出しとそのデータをクライアント側に送る時間(場合によってはSlickGridに渡すためのデータの加工時間も)が支配的になると予想される。

 

結果

SlickGrid自体のパフォーマンスには問題ない。20万件の表示完了までに7秒かかるが、巨大なテーブルを表示している自覚がある中での7秒なら固まったと思うほどではないし、頻繁に20万件を表示するわけではないし、そもそも本番ではデータの出元がMySQLになるので7秒は大きく変わる可能性がある。頻繁に20万件を表示するようなら設計から見直すべきと思ったり。

 

要件的には、時間の都合で以下が持ち越しになった。

  1. 列名のクリックイベントを取れること
  2. セル(列)の色を変えられること

1つ目は、サンプルの動きを見る限り、プラグインを参考にするか、プラグインを応用することでできそう。

2つ目もサンプルを見る限りできそうが気がする。これらはおいおい試してみる。

 

気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです) 




JavaScriptでサブウィンドウを開いたり閉じたり、関数を呼び出したり、前面に呼び戻したり

あるwebアプリを作りたくて、久々にJavaScriptのリハビリ。

親ウィンドウから子ウィンドウを開いたり、子ウィンドウの関数を実行したり、他のウィンドウに隠れた子ウィンドウを前面に出したり、閉じたりを試してみた。

 

全コード

親ウィンドウのHTML(test_window-01.html)

<html>
  <head>
    <meta charset="UTF-8">
    <title>親ウィンドウからサブウィンドウの関数を呼び出す</title>
    <script Language="JavaScript">
      var subWin = null;

      function myFunc1() { // サブウィンドウを生成
        subWin = window.open("test_window-sub-01.html","sub window","width=800,height=600");
      }
    function myFunc2() { // サブウィンドウにオブジェクトを追加
          if(check_win(subWin) == true){
              subWin.myFunc(subWin);
          }
      }
      function myFunc3() { // サブウィンドウにフォーカス
          if(check_win(subWin) == true){
              subWin.focus();
          }
      }
      function myFunc4() { // サブウィンドウを閉じる
          if(check_win(subWin) == true){
              subWin.close();
          }
      }
      function check_win(win){ // サブウィンドウの存在チェック
          if (win == null) {
              document.body.insertAdjacentHTML('beforeend', 'サブウィンドウがありません<br>');
              return false;
          }
          else if (win.closed) {
              document.body.insertAdjacentHTML('beforeend', 'サブウィンドウは閉じられています<br>');
              return false;
          }
          else{
              return true;
          }
      }
    </script>
  </head>
  <body>
    <button type="button" onclick="myFunc1()">サブウィンドウ生成</button><br>
    <button type="button" onclick="myFunc2()">サブウィンドウにオブジェクトを追加</button><br>
    <button type="button" onclick="myFunc3()">サブウィンドウにフォーカス(前面へ)</button><br>
  <button type="button" onclick="myFunc4()">サブウィンドウを閉じる</button><br>
  </body>
</html>

 

子ウィンドウのHTML(test_window-sub-01.html)

<html>
  <head>
    <meta charset="UTF-8">
    <title>親ウィンドウからサブウィンドウの関数を呼び出す</title>
    <script Language="JavaScript">
      function myFunc()
      {
          document.body.insertAdjacentHTML('beforeend', '<div>clicked !!! </div>');
      }
      </script>
  </head>
  <body>
    サブウィンドウ
  </body>
</html>

 

子ウィンドウを開く

子ウィンドウを開く関数はwindow.open()で、サンプルの「サブウィンドウ生成」ボタンを押すと下記が実行されてウィンドウが開く。

subWin = window.open("test_window-sub-01.html","sub window","width=800,height=600");

 

子ウィンドウの存在チェック

子ウィンドウの関数を呼んだりする際に、子ウィンドウが存在するか確認する必要があるケースがあるので、子ウィンドウが生成済みか、閉じられてしまったかをcheck_win()でチェック。子ウィンドウが生成されているか否かは、子ウィンドウを保持するオブジェクト(subWin)が初期値(null)であるか否かで確認するようにしてみた。開いたウィンドウが閉じられているかはwindow.closed()で確認できる。

      function check_win(win){ // サブウィンドウの存在チェック
          if (win == null) {
              document.body.insertAdjacentHTML('beforeend', 'サブウィンドウがありません<br>');
              return false;
          }
          else if (win.closed) {
              document.body.insertAdjacentHTML('beforeend', 'サブウィンドウは閉じられています<br>');
              return false;
          }
          else{
              return true;
          }
    }

 

子ウィンドウの関数を実行する

「サブウィンドウにオブジェクトを追加」ボタンを押すと、子ウィンドウのmyFunc()を呼び出す。呼び出し方は子ウィンドウのオブジェクト(subWin).関数名で呼び出せる。

     function myFunc2() { // サブウィンドウにオブジェクトを追加
          if(check_win(subWin) == true){
              subWin.myFunc(subWin);
          }
    }

 

子ウィンドウを前面に呼び戻す

開いた子ウィンドウが他のアプリの裏に隠れたときに、いちいちOSのウィンドウ操作で前に出すのは面倒なので、親ウィンドウから呼び戻せるようにしたくて「サブウィンドウにフォーカス(前面へ)」ボタンで作ってみた。前に呼び出すにはフォーカスすれば良く、window.focus()でできる。

      function myFunc3() { // サブウィンドウにフォーカス
          if(check_win(subWin) == true){
              subWin.focus();
          }
    }

 

子ウィンドウを閉じる

子ウィンドウを閉じるにはwindow.close()を実行すれば良い。「サブウィンドウを閉じる」をクリックすると実行するようにした。

      function myFunc4() { // サブウィンドウを閉じる
          if(check_win(subWin) == true){
              subWin.close();
          }
    }
 
気が向いたら感想をお願いします。(ログイン不要、ボタンを押すだけです)