CASIO KL-8500 の電池交換

当記事は、あくまで KL-8500 の話です。
他の機種・機器で同じ法則が通用するわけではないので、十分注意してください。
ソケット形状や端子の位置によっては、正しく動作しない可能性があります。

NAME LAND(ネームランド)のメモリ保護用電池の交換です。
ちなみに電池がなくても動作しますが、起動の都度、初期化を要求されたり、設定した書体選択がデフォルトに戻ったりと、色々と煩わしいです。

というわけで電池交換。ところが!!

CR2023 電池が売ってない!

実は Panasonic などの著名なメーカーは、CR2023 は終売してまして、ほぼ売ってないんですよ。
まぁ Google とかで探すと売っている店もあるんですが、さすが電池でメーカー終売してるし、電池そのものの使用期限(電池は使ってなくても劣化する)や海賊品(偽物)とかの存在を考えると、できれば通販で買いたくない。

代用品ないんだろうか?

結論

探した結果、以下の電池が代用できます。

  • CR2025
  • CR2032

実はコイン型リチウム電池にも「規格」がありまして、「C~」で始まるものであれば、公称電圧3V、「~R20~」が電池直径20.0mm、最後の2桁が高さ(電池の厚み)を現してます。

つまり、メーカー指定の CR2023 は、3V、直径20mm、厚さ2.3mmを現していて、互換性の候補は、

  • CR2025(3V、20.0mm、2.5mm)
  • CR2032(3V、20.0mm、3.2mm)

の2つが代表的選択となります。
そしてこの2つは特に問題なくソケットに挿入でき、稼働します。

ちなみに CR2016(3V、20.0mm、1.6mm)という薄型電池もありますが、こちら CR2023 よりも薄いため、電池がソケットの端子が上手く接触しない可能性があります。
実際に確認したわけではないのですが、選択しないほうが無難です。

もちろん CR2016 を2枚重ねとかは厳禁。
直列になってしまい電圧が6Vに倍増するため、最悪の場合、機器が壊れてしまいます。

対して CR2032 は、指定の CR2023 よりもかなり厚みがありますが、電池ソケットには挿入することができます。
ただし、いわゆるソケット内の「遊び」がなくなるため、次の交換時、ソケットからかなり外れにくくなります。その点覚悟してください。
自分はこれにハマってしまい、精密ドライバーで電池の表面をガリガリ傷つけながら、なんとか隙間に引っかけて取り外すことができました。

最も無難なのは CR2025。どうしても見つからないときは CR2032 を選択する、という感じですかね。

以上、あくまで延命の参考になればと思いますが、もともとメーカーサポートも切れた製品ではあるので、本体を買い換えるのが無難だと思います。

以下、余談

この機種、当時はパソコンと専用ケーブルでデータリンクできるオプションがありまして、パソコンで作成したラベルデータを直接印刷することができたのです。それが便利と思い購入しました。

しかしながら、本体のメーカーサポートが終了し、対応ソフトもサポート切れ(Windows xp までしか対応してない、バージョンアップ対応なし)となりました。
しかもデータリンクケーブルがRS-232Cだったりと、昨今のPC運用の中では使い勝手が悪くなってしまいました。

そのため長くお蔵入りしてましたが、テープカードリッジが大量残ってたのと、今回定型書式のラベルを複数印刷する必要が出てきたので、一時的に復活させて、データを直接入力して印刷することになりました。その過程で発生した出来事を記事にしてみました。

ちなみに今は、テプラに乗り換えてます。Wi-Fi対応で、プリンターとして認識できるタイプ。
ラベルプリンタも進化しました。

python2.x の csv.open() は、文字コードの対応が壊滅的

よくよく調べてみると、どうやら ASCII コード文字以外は対応していないらしい。

ということで、python3.x のインストールやり直し確定。

まぁ codec.open() 使って、あとで頑張ってパースするのもいいんですが、3.x 系で対応してるなら、わざわざ無駄な労力払わないくても、それ使えばいいじゃないですか。

どうりで、さくらのレンタルサーバだとpython 2.x系が標準で提供されてるのにもかかわらず、python 3.x 系をわざわざインストールしてる人と(いうか記事)が多いなぁと思ったら、こういうことだったのか。
2.x 系と 3.x 系の間には、文字コード関係をはじめ、かなり大きな進化点があるんですね。

なんだか 昔の Perl を思い出したよ。
jcode.pl, jcode.pm とか、懐かしいな。。。

VMWare ホストの Linux ゲストOSを、他の VMWare ホストに載せ替えた後に netconfigすると、eth0 のほかに eth1 ができてしまう

RHEL(RedHat Enterprise Linux) 5 での場合。他のブランドは知らん。

原因は、他の VMWare ホストに乗せ替えた時点で、MACアドレスが変わってしまい、それをnetconfigコマンドが「『NICが新規に刺された』と誤認識」(?)してしまうため。

以前の eth0 で設定していた情報が eth1 に移動し、移動先のVMWare ホストから割り当てられた MAC アドレスで、eth0 が作成されます。

そして、残った eth1 の情報は当然、前の VMWare ホストで稼働していた際のNICなので、このままにしておいても、何の役にも立ちません。
しかもそのままにしておくと、起動時に eth1 の情報を読み込んで、存在しないデバイスをOS内に格納されているNICデバイスドライバを総当りで探しに行ってしまいます。
その結果、起動が遅くなるうえ、起動時のメッセージがゴミだらけになります。

という訳で eth1 の情報は、残していてもあまり役に立たないので、削除するか、残しておくならば、何処かに移動してしまいましょう。

削除(移動)すべきファイルは、/etc/sysconfig/network-scripts/ の中にある ifcfg-eth1 というファイルです。

YAMAHA ルータに Poderosa でSSH接続する場合

本家のバージョン4.1.0 では、開発された時点でのSSHの暗号アルゴリズムが少ないので、NVR500に搭載されているSSHサーバの暗号アルゴリズムが解読できないみたい。

なので、オープンプロジェクト以降のバージョン4.3.0b以降~を使うのが良いかと。

YAMAHA ルータ NVR500 で DHCP 静的 IP を割り当てる方法

まぁ、ルータが壊れたので、急遽新調。
その際にNVR500を購入したので、その備忘録。

1.「かんたん設定」で、LANのDHCP割当IPの設定までやる。

ここでは、以下のような感じで。

  • 識別番号「1」
  • IPアドレス領域「192.168.100.2~192.168.100.253」
  • サブネットマスク「255.255.255.0」

2.「かんたん設定」でSSHで接続できるようにする。
あとSSHでログインするためには、ルータ(に組み込まれているOSへのログイン)ユーザ登録も必要になので、登録する。

3.静的IPを割り当てたい機材のMACアドレスを調べておく。
(実はこれが一番面倒。 )

4.SSHクライアント(TeraTermPro とか Poderosa とか)でルータにSSHログイン。

(1)管理者に成る。

> Administrator
(ここで管理者パスワードを聞かれるので、
「かんたん設定」で登録した管理者パスワードを入力。)
#

管理者になれたらプロンプトが「>」から「#」に変わる。

(2)静的割当するIPとMACを登録。(やっと本題)

# dhcp scope bind 1 192.168.100.6 ethernet 12:34:56:78:9a:bc
#

(3)最後は「保存」のコマンドを実行。

# save
#

これを忘れると、ルータの電源切ったり再起動した時に登録した情報がすべてパーとなる。

(4)確認するときは show config コマンドの結果の中から、dhcp だけを grep して確認。

#show config|grep dhcp
(結果がここにダラダラでてくる)
#

Drobo FS の SSH 上から MAC アドレスを調べる方法

ルータを新調したので、DHCP の IP 静的割当を設定したのだが、Drobo FS の MAC アドレス探しがちょっと面倒だったので、備忘録。

まぁ Drobo FS 本体に貼られているラベルを見れば、MAC アドレスは判るんだけども、肝心のラベルが本体底面に貼られているので、引っ繰り返さないと確認できないのが難点。

我が家の場合、ラベルを確認するためには、Drobo FS の電源を切って、Drobo FS 本体が格納されているラックから引き剥がす必要があって、これがラックの場所とかの関係で、ちょっと大変。

ちなみに、IP アドレスとかサブネットとかは Drobo Dashboard から設定するものなので、そこから確認できるものの、MACアドレスは確認できない。(まぁ所詮米国製なので、こういうツールの「痒いところに手が届かない」のは、 米国の仕様(=御国柄と同意)。)

ということで、パソコンからは少し面倒ではあるが、Drobo FS の組み込み Linux にアクセスして調べることに。
という訳で以下手順。

1. DroboAppsから「dropbear」(SSHサーバ)をインストール

2. SSHクライアント(TeraTermProとかPoderosaとか)でDroboFSにSSHログイン。

ここでSSHの接続が確立できない場合は、DroboApps の挙動がおかしい可能性がある。
その場合は、Drobo Dashboard の管理者設定の「DroboApps を有効化」を一度切ってから、再度入れ直す。
ちなみに Drobo FS 再起動しても、接続は改善できない。必ず上記操作が必要。

3. ログインできたら、以下のコマンド実行

# /sbin/ifconfig
(ここにMACアドレスなどのネットワーク情報が表示される。)
#

(パスが通ってないので、最初に/sbin付けて、絶対パスでコマンド実行。)

これで本体をひっくり返さずに、MACアドレスの確認ができる。

とはいえ、とても面倒。

Windows 7 Professional を Windows xp Profesional にダウングレードする

使用していたPCのうち1台が御役御免になったので、臨時(とはいえ向こう3年ぐらいは使いそうな)VHSテープ動画編集機として換装してみました。

生贄となったPC

4年ぐらい前に買ったドスパラのショップブランドPCです。今までのスペックは以下

  • OSなしモデル
  • ASUSのOEMマザー
  • Creron 2.6G
  • 1G DDR2メモリ
  • 80G SATA HDD
  • DVD-ROMドライブ
  • ATX電源(メーカー不明だけど、そこそこ普通の電源)
  • ショップブランドらしい、白い無骨なケース
  • Windows2000 Professional(正規品、別に用意した)

これを、当初は以下の通り、編集機として必要な換装するだけにしようかと思ってました。

  • Core2 Duo E2600(2.6G)
  • 2G DDR2メモリ
  • Windows xp Professional(Windows7 DSP 版のダウングレード権を行使。)
  • DVDドライブはインストールが終わったら外す。
    (編集機なので本当はRWドライブに換装が必要そうだけど、実際このマシンでデータを焼くことはない。別のマシンで焼く。)
  • ケース換装

そんなこんなで、とりあえず手始めにCPUとメモリを手配して換装してみた。
まぁ、換装する前からOEM版マザーボードはBIOSアップデートができない()と情報を得ていたので、もしかしたら「CPUがマザーボードに対応していないかもなぁ」と思っていましたが。

見事に的中

結局のところ、当時の BIOS が、その後に発売された CPU に対応していないことが原因。

まぁ、チップセットなどをみる限り、BIOS をアップデートすれば問題なさそうだというのが判明したのだが、そこで更に問題が。

OEM 版マザーボードの BIOS アップデートが存在しない

OEM 版の BIOS の提供はマザーボードのメーカーからの提供ではなく、本体を組成したメーカーに提供委ねられることが多い 。

やっとこさ JS ヘルパーのおよそのコツがつかめてきました

まぁ、JS ヘルパーを使うことによって、jQuery の記述を分離する必要がなくなるのは利点といえば利点。
でもそれ以上の不利もある。

  • 繰り返しロジックの中で JS ヘルパーを使うと、そのたびにスクリプトが生成されることになり、これはコードの無駄な冗長に繋がる。
  • ビューの HTML の中の PHP 記述の更に内側に javascript(jQuery)記述が割り込んでくるので、これがわかりにくい
  • ヘルパーで自動生成される javascript(jQuery)記述ががわかりにくい。

まぁ JS ヘルパーに限らず、全体的にヘルパーというのは、使用した際に最終的にどのような HTML になるかを少なからず想像しなくてはならないものなのだが、JS ヘルパーはその想像が難しい。
しかも CakePHP 御大が提供しているドキュメントがウンコで、とても判りにくい。結局、JS ヘルパーの場合、ヘルパーのコアソースを追うのが一番早かった。
あと、Ajax ヘルパー(prototype.js)のように、jQuery の経年による陳腐化した際の仕様変更や廃止も怖い。

こうなると javascript(jQuery)は、ヘルパーを使わずに普通に記述したほうがよいのかもしれない。

でも、JS ヘルパーを利用することにより、ソースコーディング量が減るもの事実。
実際 javascript(jQuery)を記述するよりも、ソースコーディングは減った。(結果的に生成される HTML は、javascript(jQuery)を記述するよりも大きいのだが。)

WordPress 日本語メッセージの対応(面倒臭い版)

正直なところ、直接、テーマのスタイルやPHPソースファイルを修正したほうが手っ取り早いです。参考書籍でさえ、そのような記述が為されているものが多いです。

でも折角なので、なるべく TwentyTen のテーマを構成しているソースの構成をベースに残したまま、メッセージを修正してみます。

ちなみに、WordPress の日本語版に同梱されている TwentyTen テーマは、日本語ローカライズに対応していて、元文書のPHPソースを修正せず、設定ファイルみたいな物を介して、該当箇所の英語メッセージを日本語に置換して表示しています。
今回はこの仕組みをそのまま利用するための修正方法です。

WordPress をバージョンアップするときの注意事項

テーマをカスタマイズしている場合、特に TwentyTen などWordPress のデフォルトテーマをベースに style.css などをカスタマイズしている場合は、必ずバックアップを取得する事。

バックアップせずにバージョンアップするとテンプレートも上書きされてしまいます。

まぁ、やってしまった本人が語っているので、間違いない。。。(T_T)