TKGは暇を持て余す

高時給バイトのフリーターしながらゆるゆると生きている頑張らない系趣味日記

MacでFujiXeroxの複合機(DocuCentre-V C2275)の認証情報の設定につまづいた話

ひさしぶりの更新になりました。

今月から転職して新しい職場になったのですが、職場の複合機と私物のMacの接続で手こずったので備忘録として経緯を記録します。（Qiitaでやれ）

 

弊社のプリンタは印刷時にユーザーIDとPWの設定が必要でした。

OSはMacOS Sequoia 15.4.1です。

ネットで探すと印刷時に表示されるメニューから認証情報を入力することになっているのですが、これがいくら探しても出てこない。既存の情報では、

「印刷」→「詳細設定」→「システムダイアログを使用して印刷」→「プリンタオプション」の中に認証情報の項目があるはずでしたが、探してもありませんでした。

 

試行錯誤した結果原因が判明して

「システム設定でプリンタを追加するとき『名称』欄に全角を使用するとシステムダイアログの認証情報欄が表示されなくなる」

というものでした。そんなん分かるかい。

 

ネットを探しても解決策が出てこなかったので記事にしておきます。

同じ問題に悩んでいる誰かの助けになれば幸いです。

 

 

 

ChatGPTに原因を聞いてみたので気になる人は読んでみてください。

```

「プリンタ名に全角を含めると“認証情報”が出ない → 半角名にすると出る」という再現性のある挙動は、結論から言うとmacOSの一般仕様というより、ドライバ側（印刷ダイアログ拡張/PPDまわり）の実装依存の可能性が高いです。理由を整理します。

なぜ“OSの仕様”ではなさそうか

  • macOSの印刷基盤はCUPSで、内部の“キュー名（printer-name）”は基本ASCII前提の歴史があります。CUPSの仕様や資料でも、PPDや各種識別子はASCIIで扱う前提が残っている箇所があり（PPDのベース文字列はASCII想定など）、ロケール文字列は別途ローカライズで持つのが通例です。

  • 一方で、ユーザーが見る表示名（Description/Name相当）はUnicodeで扱われること自体は珍しくありません。Appleの公式手順でも、追加時に名前・場所・ドライバを自由に指定するだけで、“全角だから機能タブを隠す”といった仕様は記載されていません。（＝OSとして意図的に制限している根拠が見当たりません）

つまり、「表示名に全角を使ったら“認証情報”タブをOSが隠す」という設計ではない。

では、なぜ起こるのか（技術的な推測）

現象から逆算すると、ドライバのUI拡張（PDE/プラグイン）やPPDオプションの読込に“キュー名”や“プリンタ名”の文字列をキーとして使っており、その処理のどこかが非ASCII（全角）で失敗している可能性が濃厚です。

ありがちなパターンは以下の通り：

  1. 文字コード/エンコーディングの想定ズレ
    UI拡張がプリンタごとの設定ファイルやPreferenceのキーをASCII前提で生成しており、全角名だと参照に失敗→拡張ペイン（認証情報）がロードされない。

  2. PPD/オプションのマッチング不成立
    PPD側の「この機種はアカウント認証可」という属性はあるが、内部名のマッチや機種判定に名前の一部を使っていて非ASCIIで分岐が落ちる。

  3. CUPSの“キュー名（ASCII）”とGUI表示名（Unicode）の取り違え
    どこかの層で表示名（あなたが付けた全角名）を“キュー名”として扱ってしまい、CUPS側と齟齬→拡張読込が失敗。

この手の“認証情報が表示されない”系は、ベンダ自身のFAQでも**「出ないことがある」旨の注意書きが散見**され（Font Bookを開いて印刷ダイアログを起こす等の迂回策まで載っている）、ドライバUIの不安定さが起因する事例が以前からあります。

反証可能性（どう切り分けるか）

あなたの観察はすでに強い根拠ですが、さらに切り分けると確度が上がります。

  • 同じ機種・同じドライバで

    • 「半角のみの名前のキュー」＝ 認証タブが常に出る

    • 「全角を含む名前のキュー」＝ 認証タブが出ない
      → このA/Bで再現するならドライバ側のバグとみなすのが妥当。

  • /var/log/cups/error_log を debug2 に
    認証タブが出ないキューで印刷ダイアログを開いた際に、PDEロード失敗やPPD読込の警告が出ていないか確認（“Unicode”/“UTF-8”/“Illegal character”系の文言がヒントになる）。

  • CUPSの内部キュー名を確認
    lpstat -v / lpstat -a で**内部キュー名（ASCII）**がどう作られているか。GUI表示名とのズレが大きいと事故りやすい。

実運用での安全策

  • プリンタの“表示名/キュー名は英数字・ハイフン/アンダースコアで統一（半角）
    → ドライバのUI機能が安定します（本件の再現からも有効）。

  • 同一プリンタに“半角名キュー”を別作成
    既存の全角名キューは残しつつ、半角名の新キューで運用確認。問題なければ切替。

  • ドライバ更新の確認
    FF Print Driver v2.6 は古めで、Sequoia（macOS 15）での未対応/周辺不具合があり得ます。より新しいPSドライバが出ていれば更新検討。

  • ベンダへのフィードバック
    「全角を含むプリンタ名だと“認証情報”が出ない」という再現手順は、ドライバ修正の良い材料になります。FUJIFILM BIのサポート/FAQにも“認証情報が表示されないとき”の項があるため、既知事象として取り込まれる可能性があります。

まとめ

  • OSの一般仕様というより、ドライバUI/拡張の実装が非ASCII名でコケていると考えるのが自然。

  • 歴史的にCUPS/PPDはASCII前提の部分が残っており、macOS側はUnicodeを許容していても、ドライバが追随できていないとこうした“タブが出ない/オプションが消える”現象が起きがち。

  • 実務対応としては半角名でキューを作るのが最善。加えてドライバ更新やログ確認、ベンダ報告を推奨。

```

 

 

AI進捗その①

AIにわたす状態空間のリストを作って

取得方法を書き込んで

エンコード方法を定義して

欠損値の扱いを決めて

etc.

 

な表を作ってたら１週間経ってました。わからないことだらけ。

聞きながらやってもわからない。手を動かしてもわからない。

それでも進んでるっぽいのが不思議。

これまでの無駄な遊びが一応活きてる。面白い。もう少し頑張ります。

バルミューダのパンを焼くアレ

こんにちわ。たかぎです。

みなさんも一度は聞いたことくらいはあるのではないでしょうか。バルミューダのパンを焼くアレを使う機会があったのでレビューをします。すでに世界中でレビューされつくしているものですが、実際のところどうなのか、素直な感想を書きたいと思います。

 

これです。

 

Amazonのレビューをみると今までのパンが見違えるように美味しくなっただの、今までのトーストには戻れないだの色々かいてありますがそれだけで買える値段ではないですよね。

ところでみなさん「いつどこで見たのかも分からないけれど、なんか頭の中にある噛むとサクっとした食感のトーストが食べたい。」こんなことを思ったことは無いでしょうか。僕はあります。

 

急に何だと思ったでしょうが、この「外はかりっと、中はもっちり」を叶えてくれるのがこのトースターです。焼いている様子を見るとわかりますが、この機種のトーストモードは規定量の水を居れて庫内が曇った状態でヒーターのON/OFFを切り替えながら最後数十秒で外側をカリっと焼くというきっと何回も研究したんだろうなあという焼き方をしています。そのため、安いパサパサの食パンを焼いても素敵な食感のトーストが焼き上がります。やや厚めの食パンを推奨時間の上限くらいで焼くのがいい感じになると思います。その出来栄えは、まさに頭の中にあるサクサクもっちりなトーストそのものだと思います。それが焦げることもパサパサになることもなく簡単に焼き上がるのはこのトースターの魅力でしょう。

しかしやはり高い値段を出して買う価値があるのかと言われると、個人的にはそうは思いません。確かに食感は素晴らしいですが、トーストはトーストです。味はほとんど食パンに依存します。

 

「確かにサクサクもっちりだけれども、決して焼いた食パンの域は出ない。」

 

これが僕の結論です。

毎日のようにトーストを食べる人でいつでもサクサクもっちりのトーストが食べたいような人でないとわざわざこの金額を出して買うことは無いと思います。あるいは旅館のモーニングで食パンをセルフで焼くために置いてあったらいいなとは思います。ただ、たまに食べるトーストのクオリティを上げるために出す金額では無いと思いました。

結論：開発者のトーストにかける情熱はすごいと思います。あとデザインは悪くないです。でも自分で買うことは無いと思います。贈り物でもらったらちょっとうれしい。

小規模事業所の勤務シフト作成自動化アプリ（遺伝的アルゴリズムを用いた最適化問題の解決）

おひさしぶりです。たかぎです。

久しぶりに更新したかと思ったら調子に乗って２記事も書きました。

 

先日いつも行っている美容院にいったところオーナーさんが「今日は野郎しか居ねえなあ」と言ってました。聞くとアシスタントさんは大体男女同じくらい出勤するようにシフトを組んでもらってるみたいですが、その日はたまたま男ばっかりになってたそうな。

シフトはスタッフさんが作ってオーナーがチェックするようですが毎月かなりの労力がかかって困っているとのこと。以前遺伝的アルゴリズムを用いた最適化の手法がシフト作成に使えると何かで見て知っていたことと、最近ポケモン自動化のためにPython触っていて頑張ればできそうだし勉強になるかなと思ったのでちょっと作ってみることにしました。

 

とりあえず遺伝的アルゴリズムの手法についてゆーちゅーぶ先生に教えてもらい、システムの要件をまとめてChatGPTに投げました。勉強になるとか言ってコード書いてないやん。

とはいえ、いきなりコード全体を作ってもらうのは無理なので、開発に必要なステップを（ChatGPTに聞いて）決めて、必要な機能を（これも聞いて）細かく分けて、それぞれのクラス、メソッドを１個ずつ作ってもらいました。そしてさいごにそーれがっちゃんこ。整合性が取れてなくてエラーの出る部分を再度ChatGPTに該当部分のコードを投げて直させて出来上がり。約900行のコード、40~50時間くらいでできたと思います。素人にしては早く出来たと思います。今月apex始めてプレイ時間が既に100時間余裕で突破したのを考えると安いもんですね。ちなみに作業時間のうち9割以上は仕事中に作ってました（？）自宅での作業時間はほぼゼロです。

 

で、出来上がったのがこちら

従業員管理から従業員情報を入力して、年・月を選んでシフト作成開始。

店の休みの日、希望の休日、従業員ごとの休日日数をセットしてシフト作成ボタンをポチッと。

 

動作はこんな感じ（確認用に動作回数を減らして試行回数1回で終わるようにしてます）

数回の試行後最も評価の高いバイトのシフト表が出力されるので、あとは人の目で確認して変えたい部分をちょっと変えればOKです。１から考えるよりははるかに楽になるはずです。

評価関数や社員属性は美容院用につくってあるのでこのまま他の事業所には使えませんが、設定をちょっといじるだけなので変更自体は簡単です。

 

という感じでシフト表自動作成プログラムを作ってみました。月数千円出せば専門家が作った高機能なアプリがあるっぽいんですけどね。

 

試作段階なのと事業所ごとに条件の設定が必要なので一般公開の予定はありませんが、必要としている方がいればTwitterでご相談ください。お安くしておきます。

 

備忘録 pandas,pandastableにおけるDataFrameオブジェクトのkeyerror

おひさしぶりです。たかぎです。

 

ちょっと知り合いに頼まれてアプリ開発をしていましたが、pandastableのDataFrameオブジェクト内でセルに直接値を入力しようとしたところ、keyerror(整数値)というエラーが返ってきてデータが編集できないという問題が発生しました。

 

ChatGPTにpandasとpandastableのエラー箇所のソースを提示して原因を聞いたところ

 

こんな感じで原因をさくっと教えてくれました。

要するにpandastable内の表の行や列のラベルに整数値の名前をつけるとプログラムが列位置なのか列の名前なのかわからなくなってエラーが発生するということみたいです。

 

panastable自体があんまり使われてないせいか日本語で調べても情報に辿り着けなかったのでいつか誰かの役にたてばと思って記事にしておきます。それにしてもChatGPT便利ですね。

備忘録（pandastableのDataFrameオブジェクトのkeyerror)

おひさしぶりです。たかぎです。

 

ちょっと知り合いに頼まれてアプリ開発をしていましたが、pandastableのDataFrameオブジェクト内でセルに直接値を入力しようとしたところ、keyerror(整数値)というエラーが返ってきてデータが編集できないという問題が発生しました。

 

ChatGPTにpandasとpandastableのエラー箇所のソースを提示して原因を聞いたところ

 

このコードを見ると、self.currentcol が列の位置（0から始まるインデックス）を参照していることが明確になります。これが self.model.getColumnType(self.currentcol) で使用され、そこでエラーが発生しています。

したがって、エラーの原因は、getColumnType() 関数が列位置を引数として受け取り、列名を取得しようとするため、整数の列名と列位置が混同されている可能性が高いです。

対策としては以下のようなものが考えられます：

  1. getColumnType() の定義を見て、列位置ではなく列名を正しく参照できるように改修する。つまり、この関数は列名を引数として受け取るべきです。

  2. handle_arrow_keys() の coltype = self.model.getColumnType(self.currentcol) の部分を改修して、列名を引数として渡すようにする。つまり、列位置（self.currentcol）から列名を取得するための変換が必要です。

以下のようなコードで列名を取得できます：

python
column_name = self.data.columns[self.currentcol] coltype = self.model.getColumnType(column_name)

ただし、この改修によって getColumnType() が列名を期待している他の箇所に影響を及ぼす可能性があるので注意が必要です。また、getColumnType() 関数がどのように定義されているかを確認することも重要です。この関数が列位置を受け取るように設計されている場合、この改修は機能しないかもしれません。

 
User
元々のDataFrameのラベルを変更して、列位置と混同されないように整数値を含まないラベルに変更することでもエラーは回避できますか
 
 
ChatGPT

はい、そのアプローチも可能です。

あなたのDataFrameでは、1から31までの整数値が列の名前として使用されています。これは列の位置と混同される可能性があるため、これを避けるために列の名前を文字列に変更することができます。

例えば、以下のように「日」という文字列を加えることで列の名前を文字列に変えることができます。

python
# Rename the columns to be 'Day1', 'Day2', etc. self.data.columns = ['名前', '職種', '性別'] + [f'日{day}' for day in range(1, days_in_month+1)] + ['休日数']

上記のコードは、日付を表す列の名前を '日1', '日2', '日3', などに変更します。こうすることで、列の位置と列の名前の混同を避けることができます。

ただし、列の名前を変更すると、その後のコードで列を参照する際にも変更を反映させる必要があります。この変更が他の箇所で予期しない影響を及ぼさないように注意してください。

 

こんな感じで原因をすぐに教えてくれました。

日記

対戦AI作りたいんだけど難しいので勉強だけしてます。強化学習でやらなきゃ無いけど大変そう。AlphaZeroのアルゴリズムをしっかり理解するレベルまでいくのが夢、無理。

対戦補助ツールはちょこちょこ機能追加とかをしてるんですが、まだ追加したい部分はあるんだけど使用感にはある程度満足してしまってるからモチベーション低下中です。誰かに使ってもらってデバッグと追加機能のリクエストとかもらえるといいんですが…出来ればPython開発環境が使える方が良いけどあんまり居ないのでこれはどっちでもいいです。協力してくれる神様が居ればDM下さい。一般公開はデバッグも十分ではなくおおっぴらに出せる形でのビルドが面倒くさすぎるのでまだ予定ありません。

 

減量中でエネルギー枯渇してて眠すぎるので早寝します。おやすみなさい。