VSCode で kintone の JS カスタマイズを書く際に ESLint のエラーを減らす

VSCode で ESLint を有効にしている状態で Kintone REST API Client を使ったコードを書いてると、こんな感じにエラーになります。

もちろん、 kintone 側の JS カスタマイズの設定で、

こんな感じに Kintone REST API Client を指定しておけば、 kintone にアップロード（または Live Server Extention などを利用）したファイルも正しく動作します。

でも、正しく動作するのに、エラー表示って、いやですよね。

いやなだけでなく、実際面でも、赤く表示が出ていても、 Kintone Rest API Client のエラーだと思い込み、大事なエラーを見逃しく易くなってしまいます。

というわけで、どうにかできないか試してみました。

node 環境に Kintone API Client をインストール

いろいろと考えたのですが、 node で開発を進めようとすると、 node 側にこれらのパッケージをインストールしておくのが一番手っ取り早そうです。

D:\work\tmp\kintone_tutorial\webpack_sample_rest_api_client>npm install --save-dev @kintone/rest-api-client

added 12 packages, and audited 392 packages in 10s

125 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

D:\work\tmp\kintone_tutorial\webpack_sample_rest_api_client>

で、コード側は import を書いておきます。

import {KintoneRestAPIClient} from "@kintone/rest-api-client";

とすると、 node でも正しくライブラリが認識されるので、エラーがでなくなります。

注意点

ただ、この場合 webpack でバンドルした際に、これらのライブラリも含んだ形になります。

webpack の externals というのを使えば、バンドル時に指定したライブラリを除外できるはずなのですが、今回試した範囲でうまく設定できませんでした。

以前は、 kintone のアップロードのサイズ制限が結構厳しかったので、ライブラリまで含めてバンドルするのは微妙なところもあったようなんですが、現在はサイズ制限が緩和された（20MBが上限）みたいで、それほど気にしなくてもよいようです。

制限値一覧 | kintone ヘルプ

ということで、 kintone のアプリの JS カスタマイズ設定で、 Kintone REST API Client を読み込まないようにだけしておきます。

Kintone UI Component も同様に対応すればよさそうです。とりあえずは、これでなんとかなりそうです。

VSCode で Python の unittest をデバッグ実行できない

こちらの記事で、 2-3 木を実装した際に、 Python の unittest を使ったテストの実行についても触れました。

この記事内では触れてなかったのですが、 VSCode で unittest を実行できるようにすると、テスト時に、 VSCode 上でデバッグもできるようになっていました。

このアイコンでデバッグ実行できます。

が、久しぶりに触ってみると、なぜかデバッグができずに、

test_SweepLineMethod (unittest.loader._FailedTest.test_SweepLineMethod) ... ERROR

======================================================================
ERROR: test_SweepLineMethod (unittest.loader._FailedTest.test_SweepLineMethod)
----------------------------------------------------------------------
ImportError: Failed to import test module: test_SweepLineMethod
Traceback (most recent call last):
  File "/home/mor/.pyenv/versions/3.11.4/lib/python3.11/unittest/loader.py", line 154, in loadTestsFromName
    module = __import__(module_name)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "（プロジェクトのパス）/test/test_SweepLineMethod.py", line 3, in <module>
    from Point import Point
ModuleNotFoundError: No module named 'Point'

のようなエラーが表示されるようになってしまってました。Point というのは自分で作成したモジュールになり、テスト用のファイルがあるフォルダの一つ上にあります。

不確かな記憶ですが、以前 unittest を試していた時（2023年6月～7月頃）はデバッグでも動かしていたはずなんですよね。

この問題（？）を解決するために、やったことをメモっておきます。

類似の現象

類似の現象がないか探してみると、 StackOverflow に

visual studio code - Unable to run python unittest in debug mode with reference to test folder in VSCODE - Stack Overflow

というのがありました。

なんでも、 VSCode 1.78.x の時は、テストが実行できていたけど、 1.80.x になったら上記のエラーが表示されるようになった、という内容のようです。状況としては似てますね。

解決策

StackOverflow の記事によると、 PYTHONPATH を指定すれば問題が解決するようです。早速試してみます。

VSCode のリファレンスを参考に、 launch.json を作成します。こにもあるように、 "purpose" を "debug-test" としておくと、テスト時に利用されるようです。

今回作った launch.json は下記のようになります。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Debug Tests",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "purpose": ["debug-test"],
            "console": "integratedTerminal",
            "justMyCode": false,
            "env": {
                "PYTHONPATH": "./"
            }
        }
    ]
}

再テスト

上記の launch.json を作って、再度テストを実行すると、今度は import エラーなど出ずに、無事にブレークポイントで止まりました。

StackOverflow の記事だと、 .env ファイルと launch.json の両方に PYTHONPATH を設定するとあったのですが、手元の環境の場合は launch.json の設定のみで問題なく動作しました。

これで、問題なくデバッグできそうです。何かのご参考までに。

2024/6/7 追記

しばらく仕事が忙しくて、 Python 周りを触っていなかったんですが、久しぶりに触ったら、また同じようなエラーが出てました。こんどは、 VSCode の UI 上で、

のような感じになっており、テストケースが全然認識されていませんでした。で、『Show output』でエラーを確認すると、上記と同じく、 ModuleNotFoundError が出ていました。

どうも、久しぶりに VSCode を立ち上げた際にアップデートが走っていたので、その影響もあるのかもしれません（この時点で 1.90.0）。

結局、こうなった理由自体はよくわからなかったんですが、上記の StackOverflow の記事にあったように .env ファイルを作成して、 PYTHONPATH を定義したら、正しく認識するようになりました。

.env

# 2024/6/7 .env ファイルを追加
PYTHONPATH="./"

とりあえずご参考までに。

オンボードグラフィック不調のため、３画面用にグラボ交換

こちらの記事で、３画面化のその後について書きましたが、その後しばらく使っていると、オンボードグラフィックにつないでいるディスプレのみ、映像が乱れたり、たまに切れたりします。

うーん、接続端子だけの問題ではなく、どうもオンボードグラフィック周りで何か問題というより故障？が起きているようです。

確か、オンボードグラフィック（ Intel UHD 750）って、CPUとの統合ですよね？オンボードグラフィックだけが使えないのならまだしも、 CPU もだめになると痛いなー。オーバークロックしたり、ハードな作業したりしてないのに壊れることもあるんだな。

まあ、 CPU がどうなるかは当面様子見るしかないので、壊れないことを祈りつつ、とりあえず快適に使えるようにするために、オンボードグラフィックは使わずに、グラボだけで３画面出力するようにしました。

グラボの選定

当初３画面化した際は、こちらの記事に書いたように、オンボード＋追加グラボで探してました。ですが、今回は追加グラボだけで３画面以上の出力を持つものを探します。

あれこれ見てると、 HDMI で３画面以上の出力できるものは数少ないのですが、 DisplayPort なら対応しているグラボがたくさんあります。

以前調べたときは、 DisplayPort だとウィンドウが勝手に移動する問題がある、というのがありましたが、改めて調べてみると、最悪の場合フリーソフトで対応できそうです。

「MonitorKeeper」でDisplayPort接続モニターのウインドウの移動をなくす | なちぶろ

なので、接続端子は HDMI に限定せずに探してみます。

あと、ディスプレイのサイズが 1920 x 1200 とちょっと変則なのですが、最近の高解像度の出力ができるグラボなら問題ないでしょう。

ということで、上記の条件を満たして、比較的安価で３画面出力ができるものを探し、今回はこれにしました。

ASRock グラフィックボード AMD Radeon RX6600 GDDR6 8GB 搭載モデル 【国内正規代理店品】 RX6600 CLD 8G

Intel の Arc を使ったグラボだと、もっと安いものもあったのですが、比較的新しいチップになるみたいなので今回は見送ることにしました。

グラボの入れ替え

PC の電源を落として、今のグラボ（玄人志向 NVIDIA GeForce GT 1030）を入れ替えます。

開封

まずは、新しいグラボ（Asrock RX6600 Challenger D 8GB）を開封します。

箱

表側

裏側

表側も裏側も保護フィルムが貼ってあるので、取付前に剥がしておきます。

パネル

HDMI の端子が端ではなく、中ほどにあるのがちょっとおもしろいです。あと、ほこりが入らないようカバーもついてますね。

端子部分

ここにもカバーがついてます。これ最初気が付かずに、なんかうまく入らないな？となってしまいました。最近のはこんなところにもカバーがあるのがあたりまえなんですかね？

ずらせば、簡単にはずれるので、取るのは簡単でした。

取付

開封を楽しんだら早速取り付けます。 PC の筐体を開けて、既存のグラボを取り外しておきます。

この新しいグラボは、補助電源が必要なので、これを新たに電源から取ってやります。

PC 購入時の付属品一式を見てみると、８ピン－８ピンのケーブルがないので、一瞬困ったなと思ったのですが、付属品に入っていた、８ピン－６ピン＋２ピンの構成のケーブルを使えばよいようです。

供給電力によっては、６ピンでいいというグラボもあるようで、こんな分割になっているようでした。

写真撮り忘れましたが、電源側は PCI Express 用の 12V の端子を使います（電源は Fractal Design ION+ 760W になるので、こちらのメーカーのサイトの写真を参考にしてください）。

で、グラボを刺して、補助電源をつなけば終わりです。

あとは、ディスプレイ、キーボードなど最低限の接続だけして、画面出力ができるか確認します。無事映りますね。

マザーボードの設定変更

ここは不要かもしれませんが、オンボードと追加グラボを同時に使うことはなくなったので、

『統合グラフィックを常に有効』を『 Disable 』に変更しておきます。なお、ついでに、『画面出力デバイスの優先順位』も『自動』にしておきます。

３画面接続

PCの筐体のふたを閉めて、今回設置したグラボに、ディスプレイも３画面で接続します（すべて DisplayPort での接続です）。WIndows を立ち上げると、最初は１画面だったのですが、しばらくすると認識されたのか３画面が表示されました。

念のため、デバイスマネージャを見ると、『ディスプレイアダプター』が RX 6600 のみになってます。

これで、無事に年始が迎えられそうです。

まとめ

久しぶりにPCの中を開けて触りましたが、最近の筐体は、配線を隠せるようになっていたりするうえ、BTO だときれいに配線してくれてますね。改めて感心しました。

あと、 Windows 11 からは、『ディスプレイ設定』に

『モニターの接続に基づいてウィンドウの位置を記憶する』というオプションが追加されており、例の DisplayPort 問題にもうまく対応できるようです。