2025年02月21日
_ [computer] Keychron V3 Max QMKワイヤレス ＆ iKBC CD108 メカニカルキーボード
Keychronのキーボードをまた買ってしまいました。
ごく個人的な好みとして、キーボードに要求したいスペックは以下の様なものです。
[1]キースイッチはメカニカルな物。種類はチェリーの茶軸が一番、赤軸でもまぁ何とか、静電容量式はどうも好みに合わない。（ショートストロークは論外）
[2]配列は、ＪＩＳの物。ＵＳ配列のキーボードが使えないのは、ちょっと悔しいし何だか情けないけど、昔から９８のキーボードを使っていたので仕方ない。（その前はFM-８だったし）
[3]接続は、やはり2.4Gの無線が良い。昔と違ってワイヤレスも改善されてデメリットな部分も減ったので、有線よりやはり無線が便利です。でもBluetooth接続の物は、キーボードに関しては使い物にならない。
概ね以上の通りですが、実際に、[1]メカニカルで茶軸、[2]ＪＩＳ配列、[3]2.4G無線接続、と３つの条件をそろえる製品は、意外と、殆どと言うかこの間まで全く有りませんでした。ＵＳ配列ならば、結構有るのですが、、
接続については、ロジクールで広く使われている"Logi Bolt"と言う2.4Gの無線接続が安定しているので、ロジクールにはずっと以前から期待していました。そこで２０２２年にやっと発売された、メカニカルで無線のキーボードが"Logicool SIGNATURE K855GR"ですが、これは赤軸のみです（チェリー製では無い）。それでもすぐ購入して、現在常用しています。大きな不満はありませんが、ちょっとガチャガチャしますかねぇ。
そんな中、先日ふと検索してみると、Keychronの、"V3 Max QMK"と言う機種が見つかりました。何と、上記の要求を全て満たしますので、早速注文しまして、本日届きました。
キーボードは上記のようなスペックの他に、実際の打ち心地が当然ながら大切になります。最近はそういう打鍵感を追求したキーボードが色々出ていまして、昨年には、有線式ですが"iKBC CD108"と言うＪＩＳ配列茶軸のキーボードを購入しました。
このiKBCの製品は、とにかく打鍵感がすごく良くて（自身の好みです）、キートップも打ちやすい感じで、とても気に入りました。まずはテンキー付きのCD108を買いましたが、それまで長らく使っていたFilcoの茶軸キーボードからこちらに交換しました。続いてテンキーレスのCD87も購入し、これも別の場所で使っていたFilcoのテンキーレスキーボードと交換しました。ワイヤレスにこだわらなければ、現状キーボードはこれに決まりです。
このiKBC CD108やCD87を2.4Gで無線化した製品がとりあえずの理想となりますが、今回の"Keychron V3 Max QMK"はかなりそれに近いものです。打鍵感もKeychronなので、まずまず良いです。
長らくＰＣ９８で、その９８のメカニカル・キーボードを使っていましたが、その後主な環境とパソコンがWindowsとPC互換機に変わって、ペタペタなメンブレ・キーボードしか無くて閉口しました。そこでキーボード変換器を探して購入し、以来長く、Windows環境でも９８用の古いキーボードを使っていましたが、チェリー茶軸のキーボードを使うようになってからは、さすがに９８キーボードは使わなくなりました。
当時２種ほど有った98KBD=>PCのキーボード変換器も、今はもう無いだろうと思っていましたが、最近、98KBD=>USBの変換器が売られている由。レトロパソコンブームの影響の様です。このまま進んで、もっと完成度の高い９８のエミュレータが出ると良いですね。（数種有る９８エミュも結構完成度高いですが、開発とかはもう止まっていますので、、）
後日追記：iKBCとKeychron V3 Maxを使い比べてみると、有線だけどやっぱりiKBCがずっと打ちやすい感じで好みです。理由はキートップにありそうです。Keychronのは、キートップ上面が丸まって面積が小さくなっています。確かに昔の高級なタイプライターはこんな感じだったと思いますが、私はiKBCの様な方が打ちやすいです。
KeychronもiKBCも、ホットスワップとかで、キースイッチから交換できるので、一度チェリーやiKBCで使っているGATERON G PROにしても良いし、そしてキートップを交換するのは是非検討したいです。それならいっそのこと、iKBCをもう一つ買って、スイッチとキートップをKeychron V3 Maxに移植してみたい気もします。
後日追記２：Keychronでは、昨年"Keychron K8 Pro"と言う機種を買っていました。すっかり忘れていました！。このキーボードは無線接続がＢＴのみなので、結局購入してそのまま棚行きで、ほぼ未使用状態です。２０２５年６月時点で見てみると、"Keychron K8 MAXと言う機種があり、２．４Ｇも使える様になっているみたいです。
2025年02月28日
_ [computer] pythonでエクセル納品書
PC98 + MS-DOS + informix3.3を、会計処理及び事務処理のプラットフォームとして長らく（３０年以上！）使用していますが、９８に繋げてあるプリンタの継続使用がどうやらもう無理そうで、伝票印字処理をWindows環境へ移行し実行しています。かといって基本Cで書かれているこのデータベースと処理は、やろうと思えばかなり細かい事まで出来るので、便利な様にかなり作り込んでありますので、過去に何度も新しい環境への移行を考えながらもその都度断念し、現在では既にもう諦めています。（この先は９８エミュかなと思っています）
とりあえずその９８で作成した印字データは、Windows環境に移してWordにて、ＰＣ接続のドットプリンタで印字させる事で凌いでいますが、ふと考えてみれば、伝票のドットインパクトプリンタでの印字発行は、既に一般的では無くなっています。複写も無い、プリンタによる単票印字が殆どです。印刷屋さんに作ってもらった、ドットプリンタ用の専用納品書も残り少なくなっている事も有り、まず納品書からwindowsからのレーザプリンタでの単票印刷にしてみる事にしました。
具体的には、９８で作った納品書データをエクセルに移して、そこから印字させればそれで良さそうです。やり方として、一つは、現在納品書発行の印字データを出力しているinformixとMS-Cのプログラム（informixレポートライターのACEは使わず、Ｃで直接書いている）を書き直して、CSV形式とかの処理しやすい出力にして、それをエクセルで読み込んで後は必要があればVBとかで整形する方法です。
もう一つは、現状のプリンタ出力用のデータを直接読み込んで、整形しつつエクセルのデータとするやり方です。
スマートなのは、当然元の出力プログラムから書き換える事ですが、今更元のＣのプログラムを書き換えるのが面倒だったので、現状のデータをpythonを使って加工して、エクセルのデータにすることにしました。
今回pythonを使うにあたり、今まではCMDと普通のエディタでのプログラミングでしたが、暫く前にVSCodeの解説本も買っている事も有り、VSCodeを使う事にしました（当方も、流行の方式に慣れなければ、です）。
常時使っている訳で無いので、すぐ仕様や文法を忘れてしまいます。pythonの本とかも買ってはあるのですが、書物の目次をひくより、最近は"python (調べたい事)"で検索した方が、ずっと早いです。
それに簡単な雛形は、ChatGPTに教えてもらった方が、より簡単です。細かい仕様まで全部AIに伝えれば、プログラムを全部書いてくれる様ですが、でもそれでは、まぁ、仕様の完備性を求めるだけで、何のプログラムを書いているのか分かりませんし、何よりおもしろくはありません。
で、書いていて、すんなりプログラムが書ける訳はなく、、
まず「確かpythonにはcase文が無かった筈なので、代わりの構文は、、」と検索してみますと、何と、最近のpythonはcase文が有るらしい。ヴァージョンによって通らないプログラムは面倒なので、ヴァージョンアップによる仕様変更は通常はあまり歓迎しないのですが、これは結構有難い変更です。私も、早速使わせて戴きます。
最初は、読み込んだ文字列をsplit()で分けて処理すればそれで楽勝、と思っていましたがそう甘くは無く（空白が不定期に入る場合が有るので）、「そんな場合は、文字列のこの部分をそのまま転記する事にして、それなら文字列のスライスで」と思ったのですが、全角と半角が混じっているのでpythonでは適切に処理できませんでした。
Shift-JISのPC98のMS-DOS環境では、半角は１バイト全角は２バイトと決まっていて、印字のカラム数も半角は１カラム全角は２カラムとなっています。それが普通だと思っていましたが、pythonは文字処理が優秀で、s="あaいb"でも、s[0]は"あ"、s[1]は"a"となります。元データに半角と全角の入り方の明確な規則が無い為、文字列のスライスでは、元の印刷データの決まったエリアを正確に選択できません。
色々調べた所、文字列を一度Shift-JISでエンコードしてバイト列に変更し、そこでスライスしてから、またShift-JISでデコードする事にしました。こんな感じです。
s_sjis=s.encode('shift_jis', errors='ignore')
ws.cell(row=i,column=3,value=s_sjis[0:24].decode('shift_jis'))
まぁ、元の出力のプログラムから書き換えればこんな事考えなくても良かった訳で、結局どっちが楽だったか微妙な所です。
その他、pythonで書いていて、この度新たに気がついた事は、print(*)の出力は、特に何も指定をせずに列記すると、出力はスペースで区切られる事。つまり、
>>> print("123","456") は、
>>> 123 456 になってしまう事に、少々びっくりした。
print()は、データ確認の為に書きかけのプログラムにはよく挿入するけど、今まで気がつかなかった（本当はVSCodeのデバック機能を使えばよいのだろうけど、私には旧来の方法で充分）。今回文字の位置を確認する為だったので、何故かスペースが多めに入っているのでprint関数の仕様を確認してみたら、
【objects を sep で区切りながらテキストストリーム file に表示し、最後に end を表示します。】
と書いて有りました。ここで、print関数の引数にsep=''と入れておけば、スペース無しになるようです。