【vi】たまに使わざるを得ない viのこれだけ覚えとけばなんとかなる知識

f:id:TsuNaMaGuRo:20220303015210p:plain
入力モード
f:id:TsuNaMaGuRo:20220303015122p:plain
編集モード

Linuxサーバー運用してるなら避けられないテキストエディタ、vi

他にもnanoとかもあるけど・・・

無駄なもん入れたくない主義のサーバーは大抵vi以外に選択肢が無いのが実情。

ガッツリ編集するならvscodeからリモート接続するけど、ちょちょいと編集するのにvscodeで接続はなかなか面倒・・・

vscodeディレクトリ移動する度にコイツ信用しますか?といちいち聞いてくるし、だいたい移動する度パスワード入れないといけないし・・・

軽く編集する程度やディレクトリ移動が頻繁にある作業の時はRLogin等のSSHクライアントを使用するほうが手っ取り早い。

そういうときにはviにお世話にならざるを得ないのである。

操作方法&コマンド集

最低限の知識

  1. viには入力モードと編集モードがある。
    • モードは他にもあるけど最低限なら覚える必要はない
    • 最初viでファイルを開いたときは入力モードになっている
  2. コマンドを入力するときは入力モード状態にする
  3. 文字とかを入力したいときは編集モード状態にする
    • 編集モードが普通のテキストエディタと同じ状態で入力モードがvi独自のコマンドを実行できる状態
  4. 特定の文字を入力後エンターを押下するとコマンドを実行可能。
    • ファイル保存等は全てコマンドで行う。以下の表を参照。

前提

  • 以下操作方法&コマンドはカーソルキーとEscキー以外は全て入力モード状態のみで実行可能
  • キーボードにカーソルキーが付いている

超最低限

説明 コマンド
カーソルを移動させる カーソルキー(←↑↓→) 編集モード中でも操作可
編集モードに移行 iキー
編集モード状態から入力モードに戻る Escキー
編集した内容を保存して終了 :wq と入力した後Enterキー
編集した内容を保存しないで終了 :q! と入力した後Enterキー
  • とりあえずはこれだけ覚えとけばファイルを編集して保存ができる。
  • なんかようわからんキーを押してしまったときは迷わず:q!だ。

スピード&作業効率アップ

説明 コマンドと補足
行数を表示させる :set numberと入力した後Enterキー
単語単位でカーソル移動 Ctrlを押下しながらカーソルキー
ファイルの先頭に移動 gg(gキーを連続で2回押下)
ファイルの最終行に移動 Gキー (Shiftキーを押下しながらgキー)
行の先頭に移動 ^キー
行の末尾に移動 $キー
カーソル行をコピー
※なお、この操作のことをviはヤンクと呼ぶ
yy (yキーを連続で2回押下)
カーソル行から下複数行をコピー 【行数】yy (カーソル行含めて下方向3行を対象とするなら3yyと入力)
カーソル行を切り取り dd (dキーを連続で2回押下)
行削除にも使える
カーソル行から下複数行を切り取り 【行数】dd (カーソル行含めて下方向5行を対象とするなら5ddと入力)
ペースト pキー
元に戻す (WindowsのCtrl + zに該当する処理) uキー
なおCtrl + zを間違えて押下するとviが閉じてしまうが慌てず冷静にfgコマンドを入力すれば元に戻る
文字列を検索(下方向) /【検索文字列】を入力した後Enterキー
hogeを検索するなら/hoge⇒Enterキー
検索結果が複数ある場合は下方向に一番近い候補に飛ぶ
文字列を検索(上方向) ?【検索文字列】を入力した後Enterキー
hogeを検索するなら?hoge⇒Enterキー
検索結果が複数ある場合は上方向に一番近い候補に飛ぶ
↑の検索でヒットした場所にカーソルを移動させる nキー
  • 書きだしたら意外と多くなってしまった

まあ言うて

これからviにお世話にならざるを得ない状況は減っていきそうですけどね・・・

ほぼ間違いなくサーバーレスが基本の時代になっていくだろうからなぁ~

【Python】配列になるはずの戻り値が何故かNoneになっちゃうよと思ってたけどそりゃそうなるだろって話

現象

  • Python再帰処理して配列をガンガン追加した結果を返すプログラムつくったった。
def main(hogelist:list) -> list:
    if len(hogelist) > 5:
        return hogelist.append("b")
    hogelist.append("a")
    return main(hogelist)

if __name__ == "__main__":
    hogelist = main([])
    print(",".join(hogelist))

実行!!

すると print(",".join(hogelist)) の部分で

TypeError: can only join an iterable

・・・例外になったった。 なぜ??

原因

return hogelist.append("b")の部分で戻り値がNoneになったから。

そりゃそうだ。

何故かhogelist.append("b")した後のhogelistが帰ってくることを期待してしまった。

実際はappendメソッドの戻り値であるNoneが返る。

Pythonは戻り値無し(void)が無くメソッドに必ず戻り値が設定されており、戻り値として何も指定しなかった場合はデフォルト値のNoneが返される。

こんなもんに2時間も迷いましたよ・・・

教訓

一文でいろいろやってそうな記述を疑え。

ディップスすると胸の真ん中が痛い

症状

ディップスすると胸の真ん中あたりが異常に痛い。

この現象に悩まされていたが原因がわかったので書く。

原因

背中が反ってる

詳細

事のはじまり

最近おっきなおムネを目指してディップスを始めた。

最初から悶絶するほど痛かった・・・

しかしよく考えもせずにまぁ筋力が足りていないのだろう!!と思いだましだましやっていた。

腕立て伏せを始めた時も同じ症状に悩まされた・・・が続けていくうちに筋力ついたのか痛くなくなった。

のでディップスも同じだろうと思っていた・・・

おかしいと気づきはじめる

しばらくディップスを続けているとおムネはちょっとだけおっきくなってきた・・・

効果はばつぐんだ!!

だけどディップスを終えた後の胸の真ん中の激痛はあいかわらず・・・

Google先生に「ディップス 痛い」とかでお伺い(検索)すると情報自体はいっぱい出てきた。

小胸筋のケガとか肋間神経痛とか・・・

でも強く押さえても全然痛くないし次の日にはすっかり治っているので違いそう。

ようやくフォームのチェックへ

原因がよくわからんままディップスを続けて、胸の真ん中の痛さに悶絶する日々を送っていた。

しかし、徐々におムネに刺激感が無くなってきた・・・

ディップスした後は大体大胸筋全体のパンプ感と胸の真ん中の激痛が混在していた。

それが今は胸の真ん中の激痛だけ・・・

負荷が足りないのであれば胸の真ん中の激痛もなくなるはずである・・・

ということでようやくフォームをチェックするという行動に出た。

無様なフォーム

とりあえず手元にあるスマホで動画取ってみた・・・

すると、スマホの中にはおケツをプリっと突き出したようなフォームでディップスに励む俺がいた。

き、キモい!!

参考にしている筋トレ系YouTuberのお手本を見る。

胸は張っても背筋はまっすぐ!!美しい。

それに対して俺のは背中が弓なりに反ってしまっており、見るからに苦しそう・・・

なによりキモい・・・

思わぬ発見

意識してディップスしてみると確かに骨盤を前に傾けてしまっている。

腹筋を締めて・・・骨盤を傾けないように・・・後はいつものように・・・身体を下ろして上げる。

おおっ!こ、これは!!!

いつものディップスの胸の真ん中の激痛が無くなり、大胸筋にがっつり刺激が入るではないか!!!

些細な違いも重要

ディップスやると毎回のように痛んでいた胸の真ん中の痛みが嘘のように改善した。

胸の真ん中にかかっていた負荷が大胸筋に分散されたような感覚である。

フォームがちょっと違うだけで筋肉の負荷の掛かり方がこんなに変わってくるんだと実感した。

まあ超重いベンチ挙げる人見てるとすっごい腰反ったりしてるから・・・そこまで・・・予想外でもないのかなぁ!?

とは言え完全に痛みがなくなったわけではない。

俺は元々反り腰気味なので、意識しないとすぐ腰を反ってしまうから・・・

というわけで、思わぬ形でディップスの胸の真ん中が痛い現象が解決したのであった。

締め

フォームの確認は大事。

【Python】pip install --upgrade pipを実行したらpipが壊れた

おこったこと

venvで作成した仮想環境にて、pipのupgradeを安易に行うと環境が壊れる可能性がある。

Windows環境で発生)

(venv)pip install --upgrade pip
...
ERROR: Could not install packages due to an EnvironmentError: [WinError 5] アクセスが
拒否されました。: 'C:\\Users\\username\\AppData\\Local\\Temp\\pip-uninstall-20ikpq2r\\pip.exe'
Consider using the `--user` option or check the permissions.

おそらく、pipのupgradeに仮想環境のPythonではなく、Windows環境上にインストールしたPythonを使用したため 権限エラーが発生したものと思われる。

このエラーが発生してしまうとpipが壊れてしまい、pipコマンド実行不可となる。

対処法

pipが壊れてしまったら潔く仮想環境を作り直すのが早い。

pipのアップグレードはpip listにWARNING表示されたコマンドを素直に使用する。

(venv) c:\work\pythonproject>pip list
Package    Version
---------- -------
pip        20.2.1
setuptools 49.2.1
WARNING: You are using pip version 20.2.1; however, version 20.3.1 is available.
You should consider upgrading via the 'c:\work\pythonproject\venv\scripts\python.exe -m pip install --upgrade pip' command.

⇒上記のc:\work\pythonproject\venv\scripts\python.exe -m pip install --upgrade pipをコピペして実行。

プログラミング コツ(自己流)1~性能より読みやすさ~

性能よりも読みやすさを重視するマインドでまいるど~

理由は ソースコードをメンテしやすい形に改修するより性能を向上させる改修のほうがカンタンだから。

例えば、DBへとアクセスを行いデータを取得する処理がある場合。

DBからのデータ入出力においてボトルネックとなりがちなのが DBへの接続処理

1回の接続であればさほど気になることはないが、何度もDBへ接続処理を行うと処理の遅さが気になってくる。

これを抑えるためには1回の処理でまとめてDBからデータを取得して接続処理の回数を少なくすればいい。

それは分かっているんだけど、最初の実装時点では 性能要件を満たしている限り遅くてもいいからシンプルにデータを取得する べき!!

理由は以下。

まとめて処理するとコードがどうしても複雑になっちゃう

複雑になったコードは読んで理解するのが困難。

読めるコードを改修するのは容易いが読めないコードを改修するのは困難。

複雑だとバグも出やすいし、テストも漏れやすい。

性能改善目的の改修はタスクとして成り立ちやすいが、コードの読みやすさのために改修するのはタスクとして成り立ちにくい

趣味であれば自由にできるけど、仕事でコードを書いている場合。

性能が悪いから改善して!というタスクはユーザーに関わるタスクのため今必要な仕事として着手できる。

しかし、コードが読みにくいっていうのはユーザーにとって何の関わりもないタスクだし、後回しにされやすい。

性能が事足りていれば手を付けられることもなく、次にそのコードに触るときは新項目を追加する等DBや処理内容に修正が入るときになる。

この時点でコードが複雑になっているとデグレードが恐ろしくてリファクタリングしにくくなっちゃう。

リファクタリングしてデグレードしたら原因の切り分けがちょっと大変になるし。

大して性能差が出ない場合も多い

確かにまとめて処理した方が早いのだが、その差が0.2秒だとかの差である場合も多い。

数字上は確かに早くてもユーザーの使用感としてはどちらも変わんねぇよ?ってなる。

また明らかな差があったとしても使用していてストレスを感じないのであれば上記に書いたデメリットを鑑みてソースコードをシンプルに保つべき。

性能改善は最悪マシンのスペックアップでどうにかなる

この手を最初から期待するようになると技術者としてど~なの?って感じだけど・・・

今はクラウドネイティブの時代でサーバースペックの変更がほんの数分でできるようになり、ハードウェアの変更に対する敷居は下がっている。

組み込み系やビッグデータの取込処理ならまた話は別だが、少なくとも昔みたいにメモリまで制御意識して処理の高速化を図るなんてことは少なくなった。

最初はシンプルなコードで実装して、問題が発生したとき初めて性能改善する

というコードの組み方にするのが今のワタシのベストプラクティス。

一回作り終わったら縁を切るんじゃなくて、段階を踏んでちょっとずつ改善していく心構えで実装していかなくてはいけないと思うよ。

まぁ、コードの複雑さに泣きそうになるときって大抵他人が書いたコードを改修するときなんですけどね・・・