Code Spell CheckerというExtensionをインストールしたんですが、スペルチェックが有効にならないファイルがありました。
拡張子を登録する必要がありました。Visual Studio Codeの左下の歯車アイコンをクリックしてSettings画面を開く。Extensions -> Code Spell Checkerを選択する。「C Spell: Enabled Language lds」欄の「Add Item」ボタンを押して、スペルチェッカーを有効にしたいファイルの拡張子を追加する。
Windowsの「Visual Studio Code」に「Remote - SSH」というExtentionをインストールして、リモートのLinux上のファイルを編集しようとしたら意味不明なエラーが出ました。
[14:32:37.168] Log Level: 2
[14:32:37.170] remote-ssh@0.56.0
[14:32:37.170] win32 x64
[14:32:37.172] SSH Resolver called for "ssh-remote+接続したいLinuxマシンのホスト名", attempt 1
[14:32:37.172] SSH Resolver called for host: 接続したいLinuxマシンのホスト名
[14:32:37.172] Setting up SSH remote "接続したいLinuxマシンのホスト名"
[14:32:37.188] Using commit id "e5a624b788d92b8d34d1392e4c4d9789406efe8f" and quality "stable" for server
[14:32:37.189] Install and start server if needed
[14:33:01.718] getPlatformForHost was canceled
[14:33:01.722] Resolver error: Error: Connecting was canceled
at Function.Canceled (c:\Users\xxx\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:94623)
at c:\Users\xxx\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:104886
at processTicksAndRejections (internal/process/task_queues.js:94:5)
at async Object.t.withShowDetailsEvent (c:\Users\xxx\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:110096)
at async Object.t.resolve (c:\Users\xxx\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:108158)
at async c:\Users\xxx\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:143767
[14:33:01.724] ------
接続先のOSを指定する必要がありました。 qiita.com
以下の設定をsettings.jsonに追記したら接続できました。
"remote.SSH.remotePlatform": {
"接続したいLinuxマシンのホスト名": "linux"
}
後で気づきましたが、接続時にひっそりと以下の選択肢が表示されていました。モーダルダイアログで表示されないので非常に気づきにくいです。
ここでLinuxなどをクリックすれば、対応する設定がsettings.jsonに追記されます。
というかなんでOSの種類が事前に必要なのか全く意味が分かりませんね。sshで接続した後でOSの種類を調べるのは容易だと思います・・・。
ちなみに、他に気になった点として、Visual Studio CodeのRemote SSHで接続すると、sshのセッションだけでなく 接続先のホスト上で勝手にnodeのプロセスが立ち上げられます。nodeが必要ということはAlpine LinuxなんかのミニマムなLinuxでは動作しないでしょう。 なぜかVisual Studio Codeはローカルではなくホスト側でExtentionを実行する仕様らしいです。Extentionの管理画面もローカルとホストが分けられています。なんでそんな仕様なんだ・・・。
それと、このnodeプロセスが結構メモリを消費するので、スペックの低い最小構成のマシンにRemote SSHするのも難しそうです。
というわけで「Visual Studio Code」で「Remote - SSH」を使ってみましたが、私の期待したものとはちょっと違っていました。結局代わりに「SSH FS」というExtentionを使用することにしました。 qiita.com
dockerコマンドに
--memory-swappiness=0
を付けて起動する
--memory-swappiness=0
このオプションを付けておけば、バックグラウンドでメモリ消費の多い処理を実行しても、そのDockerプロセスはスワップアウトされない。他のプロセスがスワップ・アウトされる。応答時間が重要なWebサーバーなどに付けておくと、メンテナンス時にいい感じで動いてくれる。
参考文献:
デフォルトでは、コンテナのカーネルは、アノニマス・ページ・メモリ上の何パーセントかをスワップ・アウトします。コンテナ向けのこのパーセントを指定するには --memory-swappiness で 0 ～ 100 までの値を設定します。 docs.docker.jp
ただ、このやり方だとZram使用時にはうまく動かなさそうだ。Zramにも全くスワップされなくなってしまうだろう。
自作キーボードキットを買って組み立てたのでレビューしてみます。
キットはRunner3680という直行配列キーボードのキット。
スイッチはKailh Speed Silverというゲーマー向けのスイッチ。
キーキャップは「無銘誠品」と箱に書いてある謎メーカーのDSA Lazer Etched PBT Keycaps ALL 1U Blackというもの。
もげやすいとは聞いてましたが、「まあいうてもそんなもげへんやろ」と思ってたら、あっさり3回もげました。3回目はパターンごともげたので修理に余計な時間を費やしてしまいました。皆さんはもげる前に対策してください。
UEWで配線する方法はELMのChaNさんから学んだやり方なのですが、実はあんまりメジャーなやり方じゃないことを最近知りました。皆さんは何でジャンパーしていますか？
幸いRunner3680のキットはコンスルーという取り外しできるヘッダピンを介してArduinoが接続されている設計なので、修理することができました。Arduinoの接続にはコンスルーを使っておくのがよいでしょう。
私は手が小さくて遠くのキーに指を伸ばすのが苦手なので、直行配列にしたら指が届きやすくなるのではと期待して直行配列にしたのですが、別にそんなことはなかったです。なかなか直行配列に慣れなくて誤入力が多発します。
スピードスイッチと呼ばれる非常に軽いスイッチと聞いて購入したのですが、実際は押下圧40gなので別に軽くはないというか赤軸と同レベルです。ONになるまでのストロークが非常に短くて1mm押し下げただけで反応します。どのくらい敏感かというとホームポジションを指で探るだけで反応するぐらいの敏感さです。感覚的にはほとんど触るだけで反応する感じです。直行配列になれないこともあって、ちょっと指が隣のキーに触ったり、掌がキーに触れただけでキーが反応して、誤入力が大量発生します。反応がクイックなのでゲーム用にはいいのかもしれませんが、文章を入力する用途には向いてない気がします。誤爆しないように手を浮かせ気味にする必要があるので、肩がこります。
自作キーボードはケースが厚めになるのでキーの高さもちょっと高くなります。Runner3680は2重基板なのでさらにちょっと高めです。Kailh Speed Silverのおかげでキーに掌が触れると誤入力が起こるので困ります。ロープロファイルスイッチにすればよかったかもしれません。自作キーボードキットを選ぶ時にはキーの高さも確かめるべきでしょう。
キーキャップが汚れるといくら拭いても汚れが落ちません。刻印に汚れが染み込んでしまうようです。画像ではわかりづらいですがKやNの文字が黒ずんでいます。まだほとんど使用してないんですけどね。このキーキャップは刻印が「レーザー彫刻」なのですが、刻印は2色成型かシールの方がよさそうです。
見てのとおりRunner3680は全キーが1Uというサイズの小さいキーです。CtrlやShift、Enterキーもアルファベットと同じキーの大きさです。私は（だいたいの人がそうだと思いますが）CtrlやShiftを指をずらしながら押すので、キーが小さいと非常に入力しづらいです。ゲームする時はCtrlやShiftを多用するので困ります。
ファンクションキーが少ないのはIDE使う時にやっぱり困ります。
部品の組み合わせが悪かった気がします。ゲーム用途にするならKailh Speed SilverでCtrlやShiftの大きいキーボードにするべきでした。仕事用ならフルキーボード（テンキーやファンクションキーは外付けでいいかも）で、赤軸、Row-Staggered配列と保守的な構成にするべきだと感じました。
今までVisual Studio上のPTVS(Python Tools for Visual Studio)でDjango開発してたのですが、いろいろ不便になったり、マイクロソフトもやる気なさそうなので、PyCharmに移行しました。
私の場合は有料版のPyCharm使うほどでもないので、無料のPyCharm Community EditionでDjangoが開発できるよう設定しました。その方法を記録しておきます。
ちなみに、今から挑戦する人はいないと思いますが、Visual StudioでPythonのWebアプリを開発するのはメリット皆無っぽいのでおすすめしません。Webではない普通のPython開発なら、Cコンパイラが必要になったりするのでアリかもしれません。
有料版PyCharmはDjangoプロジェクトに対応していて、既存のDjangoプロジェクトを読み込んだり、Djangoプロジェクトを新規作成できたり、デバッグ時のプログラム起動テンプレートが用意されています。
無料版にはそういう機能がないので、開発時にはIDEを使わないDjango開発の場合と同様に、Djangoに含まれている「manage.py」等のユーティリティーを使用します。Djangoプロジェクトとは言っても普通のPythonプロジェクトなので、普通のPythonプロジェクトとしてPyCharm Community Editionで開発できます。
PyCharm Community EditionでDjangoプロジェクトを作るには、まずメニューのFile -> New Project...で普通のPythonプロジェクトを作ります。
Djangoを仮想環境にインストールします。さっき作成したプロジェクトのウインドウで、File -> Settings -> Project: プロジェクト名 -> Python Interpreterを選択します。
「+」ボタンをクリックすると「Available Packages」ウインドウが開くので、検索ボックスに「Django」と入力して、候補からDjangoを選択します。Specify versionをクリックしてインストールしたいDjangoのバージョンを指定して、「Install Package」ボタンをクリックします。
Djangoがインストールできたか確認します。PyCharmのウインドウの下部に「Terminal」というタブがあるのでクリックしてターミナルを開きます。
python -m django --version
と入力してバージョンが表示されればインストールできています。
次のコマンドでDjangoプロジェクトのひな形を作成します。設定ディレクトリ名はakiyokoさんに倣って「config」としています。（Django では、コンフィグディレクトリの名前もプロジェクト名と同じになってしまうため、一度、config という名前でプロジェクトを作成し、その後、ディレクトリ名を変更するのがおすすめだそうです: Django入門 (チュートリアル) - とほほのWWW入門）
django-admin startproject config .
以上でDjangoプロジェクトの作成は終了です。
次のコマンドでDjangoプロジェクトが動作するか確認します。
python manage.py runserver
ターミナルに次の出力が確認できるでしょう。
Performing system checks... System check identified no issues (0 silenced). You have 13 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, conte nttypes, sessions. Run 'python manage.py migrate' to apply them. September 20, 2020 - 18:22:06 Django version 1.11.29, using settings 'config.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CTRL-BREAK.
ターミナルに出力されたローカルURLhttp://127.0.0.1:8000/をクリックすれば、Djangoの出力がブラウザに表示されるはずです。
PyCharm以外で作ったDjangoプロジェクトを読み込むには、File -> Openでプロジェクトのディレクトリを指定して「OK」ボタンを押します。
PyCharm以外で作ったDjangoプロジェクトを読み込むと、設定が変になっていることがあります。File -> Settingsで設定画面を開いて、Project:プロジェクト名 -> Project Interpreterで、Pythonインタプリタが適切に設定されているか確認します。
インタプリタの設定が変になっていたら、新規にVirtualenvの仮想環境を追加するのがよいでしょう。
歯車アイコンをクリックして、Addをクリックすると、Pythonインタプリタを追加できます。今回は以下の設定で追加しました。
仮想環境のPythonインタプリタが追加されました。
以上で補足は終わりです。
デバッグ時に実行するコマンドを設定します。これを設定するとデバッグ時にPyCharmからDjangoサーバーを起動できるので便利です。
メニューからRun -> Edit Configurationsをクリックします。
「+」ボタンをクリックすると、テンプレートの選択肢が表示されるので、「Python」を選択します。「Python」テンプレートを選択すると普通のPythonプログラムとしてのデバッグコマンドを設定できます。
設定はmanage.pyに引数を与えてDjangoサーバーを起動する様な設定にすれば何でもOKです。
「Name」には適当な名前を入力します。例ではWooHooAppにしています。「runserver」とかでもいいかも
「Script path」にはmanage.pyのパスを与えます。
「Parameters」にはmanage.pyに与える引数を入力します。例では、「runserver localhost:8080」にしています。
「Environment variables」にはデバッグ時に設定したい環境変数をセミコロンで区切って入力します。
私の場合デバッグ時には別の設定を使用したいことが多いので、あらかじめ「;DJANGO_SETTINGS_MODULE=WooHooApp.settings」を追加しています。DJANGO_SETTINGS_MODULEを変更することで設定モジュールを切り替えることができます。
設定が入力できたら「OK」ボタンをクリックして、メイン画面に戻ります。
メニューからRun -> Debugをクリックすると、設定を選ぶダイアログが表示されるので、起動したい設定名(ここではWooHooApp)をクリックします。
コンソールに出力が流れます。
ターミナルに出力されたローカルURLhttp://localhost:8080/をクリックすれば、Djangoの出力がブラウザに表示されるはずです。
私の少ない予算だとVirtual Machineのメモリが不足気味なので、メモリ消費量の少ないLinuxディストリビューションを探してみた。
AzureでB1sサイズのVirtual Machineを作成して、起動後しばらくしてからfreeコマンドでメモリ消費量を比較した。条件を揃えるためDockerデーモンとMicrosoft Azure Linux Agentは起動させている。
このavailableのサイズが、いわゆる空きメモリのサイズと考えてよいだろう。
man free(1) - Linux manual pageによると、availableとは新しいアプリケーションの起動時にスワップせずに使えるメモリ量とのこと。
available
Estimation of how much memory is available for starting new
applications, without swapping. Unlike the data provided by the
cache or free fields, this field takes into account page cache
and also that not all reclaimable memory slabs will be reclaimed
due to items being in use (MemAvailable in /proc/meminfo, avail‐
able on kernels 3.14, emulated on kernels 2.6.27+, otherwise the
same as free)
manの記述を信じるならGentooは省メモリということになる。一方CoreOSはavailableが極端に少ないバックグラウンドで何か管理用のソフトが動いているのだろうか。
CoreOSはメモリ消費が少ないという情報があったので期待していたが、usedメモリは240MBということでいたって平凡である。availableも少ない。 この記事だとメモリ消費量は160M程度だと書かれているのだけれど。 qiita.com
ちょっと興味深いのが、同じサイズのインスタンスなのにtotalメモリに差があること。
man freeによると、totalは/proc/meminfoのMemTotalとSwapTotalを参照している。
total Total installed memory (MemTotal and SwapTotal in /proc/meminfo)
さらにMemTotalとは、man proc(5) - Linux manual pageによると、物理メモリから予約分とカーネルを差し引いたものだそうだ。
MemTotal %lu
Total usable RAM (i.e., physical RAM minus a few reserved
bits and the kernel binary code).
Gentoo Linuxはなぜかtotalメモリが多い。使用したGentoo Linuxは、特にカーネルをチューニングしているわけではなく、Hyper-Vとdockerのオプションを追加した程度である。
Gentoo LiveDVDのカーネルコンフィグは結構オプションが削減されているようで、vmlinuzのサイズはgentoo-sourcesベースが6.6MBで、LiveDVDベースが4.3MBだった。LiveDVDはオプションてんこ盛りになっているのと思ってたので意外。
ちなみに最初、Hyper-Vの動的メモリ割り当ての影響があるのかもと思ったが、Hyper-Vの動的メモリはusedで調整されるようだ。（メモリ割り当てが削減されるとusedが増える）
意外とGentooが省メモリだった。
CoreOSは事前情報に反してメモリ消費が多くて、メモリが512MBのインスタンスだと起動すらできなかった。。。大きいインスタンス上での、複数のdockerイメージの運用を想定しているのだろうか。
