完全に個人的な備忘録

完全に個人的な備忘録。学習コストが高くなってきたので、メモしておかないと…片っ端から忘却の彼方なのです。

MSRドラゴンフライが点火しない

何時もと趣向が違いますが、これも備忘録なので、ここに書いちゃいます。

アウトドア用のストーブ(日本だと焜炉と言った方が良いかな)にMSRドラゴンフライという物があります。

私は外でごはんを食べるのが好きなので、アウトドア用のストーブ(焜炉)を沢山所有していたりするのですが、冬になると、燃料が灯油のストーブ(焜炉)を使う事が多くなります。

灯油燃料のストーブは点火にややコツがあります。といっても、基本的にはプレヒートをしっかり行なえば良いだけなのですが。

で、この前、経験した、点火しない事件を備忘録として記録しておきます。

現象は、きちんとポンピングして、プレヒートしているのですが、fuelラインを空けても全く点火しないのです。勿論、燃料が無いという落ちではありません。

あまり、Fuelラインを開けておくと、火柱が上るので、直ぐに閉じて。為念、プレヒートをやり直し、ポンピングしてFuelラインを開いて…やっぱり、着きません。

で、ここで、少し気が付いた事が…fuelラインを開けた時に「プシュー」っと燃料を吹いているような音はするのです。でも、着かない…

原因は、ポンプの保存方法が悪かったらしく、ポンプのストローみたいな奴(ディップラインって言うらしい)が曲っていて、燃料の上に出ていたらしいのです。で、それを180度回転させる事によって、解決しました。

f:id:tarancho:20180118233958j:plain
ディップラインが変な方向に曲ってた…

ちゃんと忘れないように備忘録に書いておこうって…っていう事で、これを書いているわけです

が…

MSRストーブメンテナンス

に全く同じ事が書かれていました。一部を以下に引用しておきます。

f:id:tarancho:20180118234604p:plain

ちゃんと忘れないようにしておこう…

フィッシング(詐欺)メールがきたよ

フィッシング(詐欺)メールが来るのは珍しい事ではないんだけど、なかなか巧妙だったので、記録しておきます。
以下のようなメールがきました。
f:id:tarancho:20170923185631j:plain
「あなたのアカウントは一時停止されました」と…でも、少し日本語が変な部分がありますね。「あなたが本当にあなたでないなら」とか、意味がわかりません。

で、巧妙なのは、本物の正しいURLが表示されているんですよね。でも、クリックすると、短縮URL

http://owどっとly/5iy930fluDq

に飛ぶんだけどね。これって、htmlメールの弱点ですね。因みに上のURLはクリックできないように一部を書き換えています。

で、試しに、短縮URLを入力してみたところ、以下のサイトに飛びました。

f:id:tarancho:20170923190546p:plain

本文のURLは amazon だったけど、飛び先は amazun でしたね。もう、この時点で詐欺だってわかりますね。ためしにメールアドレスとパスワードを入力してみます。

f:id:tarancho:20170923190816p:plain

なんと、これで、ログインできちゃうんですよ。つまり、チェックしていないって事ですね。そして、疑わしい活動が検出されたので、セキュリティ上の観点からカード情報を入力しろと…

f:id:tarancho:20170923195719p:plain


で、入力すると、本物の amazon のページにジャンプします、

f:id:tarancho:20170923195339p:plain

これって、騙される人がいるかもしれないですね。

run-parts の name space

ま〜、これも、実はかなり前に経験した事なんだけど、今更ながら書いておこう。

日次処理が実行されない…

何時もはcrontabを使用する事が多いが、今回は、面倒だったので、

/etc/cron.daily/

スクリプトをほうりこんだ。しかし、実行されない・・・

man run-parts
run-parts - run scripts or programs in a directory

を確認すると…

Debian cron script namespace (^[a-zA-Z0-9_-]+$).

という記述が…なんと、ドットが使えないのか… ‾が使えないのは知ってたんだけど。バックアップファイルは無視してくれんだ…ぐらいに思っていたけど、ちゃんと調べるべきでした。

…っという話。

日付変換色々

日付変換色々。これは、本当に備忘録です。

  • unitimeへの変換
$ date +%s
1417219811
  • unixtimeから変換
$ date --date @1417219811
20141129日 土曜日 09:10:11 JST
  • unixtimeへの変換(特定の日時)
$ date +%s --date '1970-1-1 0:0:0'
-32400
  • unixtimeから変換
$ date --date @-32400
197011日 木曜日 00:00:00 JST
  • unixtimeからExcel timeへの変換

excelのシリアル値は1日(24時間)が1なので、60秒×60分×24時間=86400で割れば良い。そして、基点が異なるんで、unixtimeの起点を加算する。1970/1/1を、excelのシリアル値で表現すると25569となる。

(unixtime / 86400) + 25569

f:id:tarancho:20150701210649p:plain

  • exceltimeからunixtimeへの変換
(Excel Timestamp - 25569) * 86400

excelは1日(24時間)が1なので例えば、9時間の場合は

1/24 * 9

f:id:tarancho:20150701210659p:plain

閏秒

今日は閏秒という事なので、多分、大丈夫だろうとは思いつつも、為念、確認していました。

以下のようなスクリプトを実行して、画面を眺めていたところ…

while :
do
    date
    sleep 0.75
done

ほ~、60秒にはならなかったけど、59秒が長いですな~。

Wed Jul  1 08:59:56 JST 2015
Wed Jul  1 08:59:57 JST 2015
Wed Jul  1 08:59:58 JST 2015
Wed Jul  1 08:59:59 JST 2015
Wed Jul  1 08:59:59 JST 2015
Wed Jul  1 08:59:59 JST 2015
Wed Jul  1 09:00:00 JST 2015
Wed Jul  1 09:00:01 JST 2015

ちゃんと、閏秒を認識しているんだ。
f:id:tarancho:20150701210115p:plain

getopt って

getoptって何時の間にか、MinGWとか gccの -mno-cygwin オプションでもサポートされていたんですね。

今迄、個別に getopt のソースをbuildして使っていたのですが、そんな事は不要になっていたようです。

今頃知ったのかっていうと、一年ぐらい前に知ったんだけど、備忘録として記録しておきます。

VBAの実行時 MSRDO20.dll が無いと言われる

VBAの実行時 MSRDO20.dll が無いと言われた時の備忘録。原因は、以下の通り。

Support Statement for Visual Basic 6.0 | Microsoft Docs

Windows 7から MSRDO20.dll がデフォルトではインストールされなくなったから。直接、Visual Basic 6.0を使用しているわけではないが、VBAからVBのDAOを実行していると発生してしまう。DAOを使用しないで、別の方法で実現すれば良いのだが、今、過去に作ったVBAのマクロを修正している暇はない。

って事で、MSRDO20.dll を何らかの方法で入手して、システムフォルダ(例えばC:¥Windows¥System32¥MSRDO20.dll)に複写し、regsrv32でレジストします。

>regsvr32.exe C:¥Windows¥System32¥MSRDO20.dll

f:id:tarancho:20140712075633p:plain

とりあえず、これで使えるようになります。

Windows10 64bitの場合の留意点

(2019-05-17追記)
Windows10 というか 64bit OSの場合は、dllファイルの置き場所は System32 ではなく、SysWOW64 ディレクトリになります。

f:id:tarancho:20190517083245p:plain
エラーコード 0x80004005

それと、これも Windows 10 に限った事ではないですが、regsvr32 コマンドを実行するコマンドプロンプトは管理者で機動しないと エラーコード 0x80004005 が発生します。