vi : コピペとカトぺ

viのコピペ/カトペは、

  • 対象が行か単語か文字か?
  • コピーかペーストか?
  • カーソルの前か後ろ(上下、左右)か?

あたりを整理して覚えておくこと。

  • yy →カーソルのあるコピー
  • yw →カーソルのある単語コピー
  • dd →カーソルのある切り取り
  • dw →カーソルのある単語切り取り
  • x →カーソルの右1文字を切り取り
  • X →カーソルの左1文字を切り取り

 

2021/6/15 draft

vi : 編集の終わりかた(ファイルの閉じかた)

保存する/しない、強制的にxxする/しない、別のファイルをオープンする/しない、で終わり方がいろいろある。

資格試験では、問題文から上記前提条件を早く認知するようにしたい。

  • :q →終了。変更があると終われません。
  • :q! →強制終了。変更を無視して終わります。
  • :w →保存して終わらない。
  • :w! →読み取り専用でも強制的に保存。
  • :wq →保存して終了 :x, ZZと同じ。w権限がないとエラーになる。
  • :wq! →読み取り専用でも強制的に保存して終了
  • :e ファイル名 →今のファイルを閉じて新しいファイルをオープン。今のファイルに変更があるとエラーでそのまま。
  • :e! ファイル名 →今のファイルを前回の保存の状態で閉じる(変更を無視)。ファイルを開く。
  • :e! →ファイル名を書かないと、今のファイルを前回の保存の状態に戻して、終わらない。

試験対策としては、!を付けた時の作用や動作が基のコマンドにより微妙に異なるので、その辺を整理して覚えた方が良い。

  • :q!は、変更を無視して、終了を強行。
  • :w!、:wq!は、Read-onlyオプションを無視して保存を強行。
  • :e1!は、変更を無視して、他のファイルのオープンを強行。

みたく。

あとは、:wqと同等のコマンドとして :x, ZZを思い出せるかどうか。

 

 

 

CentOS Linux Release 7.9.2009で一部確認)

2021/6/9

vi : 検索

検索

ファイル内で特定の文字列を検索する時には、

  • /文字列

見つかった文字列は反転とか色が変わるとかで表示されるが、それらを順番にカーソル移動で追いかける時は、

  • n

を繰り返す。

で、これはファイルの先頭から末尾に向けての検索の場合。

 

逆方向に検索する時には、

  • ?文字列

カーソルを移動する時には、

  • N

をくりかえす。

実行例。まず123を検索する。

f:id:huamutou:20210609002745p:plain

ヒットした部分がハイライトされ、カーソルは最初の123へ。

f:id:huamutou:20210609002756p:plain

ここでnを押すと次の123へ。

f:id:huamutou:20210609002804p:plain

今度は、Nで最初の123へもどる。

f:id:huamutou:20210609003325p:plain

 ?も同様。

 

何故 ”/” と ”?” かな?、覚えにくいな、と思ったが実際に実行するとキーボードのキーバインディングのせいのようだ。つまり、/と?は同じキーに割り当てられていて("shift" + "/" = "?")、最初に/が検索コマンドと決まったけど、広報検索が必要になった時に覚えやすいように同じキーの?を採用した、、、という風に覚えることにする。

 

 (CentOS Linux Release 7.9.2009(core)で確認。)

 

2021/6/8

 

vi : カーソル・画面移動に関するコマンド

viコマンドモードにおけるカーソル移動のコマンドがなかなか覚えられないので、ここにまとめ。

説明の前提は、

  • 矩形囲み(画面)は、テキストファイルのうち、エディター画面に表示されている部分を表す。
  • 矩形囲み(ファイル)は、テキストファイル全体。よって、ファイル内&画面外の部分は、表示されていない部分。
  • グレー矩形はテキスト1文字を表す。
  • 矩形(カーソル)-つまりど真ん中-は、現在のカーソルの位置。
  • 矩形(コマンド-hjkl0$HLggG)は、現在カーソル位置でコマンドを叩いた時のカーソルの移動先。

f:id:huamutou:20210608144212p:plain

カーソル、画面操作に関するviコマンド

コマンド説明

  • h, j, k, l→カーソルの左下右上への移動(これは基本)
  • H→画面表示の先頭行。これは、h→左に1文字、H→画面左端、とペアで覚える)
  • L→画面表示の最終行。これは、l→右に1文字、L→画面右端、とペアで覚える)
  • 0, $→カーソルが位置する行の先頭または末尾への移動
  • gg, G→ファイルの先頭または最終行。(画面表示の先頭、末尾ではない)

そのほかに、

  • ctrl+b, ctrl+f→前または次のページに移動
  • w →スペースをスキップして次の文字に移動。但し、カンマやタブなどの記号で区切るとでは、区切り文字と普通文字の両方で停まる。
  • :n→ファイルのn行目に移動
  • hjklHGは、頭に数字をつけると数字の分だけ(n行、n文字)跳ぶ。したがって、nG→n行目に移動で :nと同じ。
    nを付けるとnHとnGは同じ動作になるようだ。

ちなみに、最後の:n、nGを使う時によく併用するのが、行番号の表示/取り消し。

  • :set number ⇄ :set nonumber
  • :set nu ⇄ :set nonu

 f:id:huamutou:20210609010439p:plain

f:id:huamutou:20210609010629p:plain

省略形が nu(ぬ) とか nonu(のぬ) で気持ち悪いので注意。

 (CentOS Linux Release 7.9.2009(core)で確認。)

2021/06/08

損をしない株式投資〜手仕舞い/損切りポイントの設定とMACDによる銘柄選抜

個人で株式投資を行う場合に、大損しないための自分ルールのメモ。

手仕舞いポイントと損切りポイントを事前に決める

 手仕舞いポイントは、買値に対して何%高で売るか。数日保有のスィングトレードなので、あまり上値を追うと売りタイミングを逃して下げに入ってしまい、身動きできなくなる期間が増えてしまう。

 損切りポイントは、値下がった時に無条件で売るポイント値下がった時に自分の意思で手入力で損切り売りをするのはほぼできない。絶対できない。だから、損切りポイントも事前に決めておき、必ず逆指値で指定しておく。現在は、5%

  • 例:「買値1000円の株は、950円を下回った時に成行で売る。有効期間は今月中」

 現在は、手仕舞いポイント=10%、損切ポイント=5% としている。そうすると、理論的には、勝ちと負けが五分五分でも5%の利益が確保されることになる。実際には、周囲の状況に応じて3−9%で手仕舞うこともあるし、10%超えを追うこともある。あくまでもそれは材料次第であるが、前提としてはその時点での負けを埋めて利益を出せるかどうかで判断する。

できるだけ多くの銘柄を買い、値上銘柄数➗買い銘柄数>50%を維持する

損切り5%、手仕舞い10%のルールを守れば、値上銘柄数>値下銘柄数を維持すれば、利益が出ることになる。実際、百発百中で値上銘柄を探すのは難しいし、気持ちが疲労する作業。それよりも、資金が許す範囲で多くの銘柄を買い、結果として値上銘柄の方が多くなる状況を狙った方が簡単。

実際、値上がり銘柄を選別するための方法は、ネットからいくらでも得られるので、ここから自分が気に入った、かつ、実験で良い結果が得られた指標を選べば良い。

 

SAP HANAのMDCとシステムレプリケーションの相性がよくない、という話。

SAP HANAのMDC(Multi Tenant database Container)は複数のテナントDB、つまりユーザーDBを運用できる仕組み。

だから当然、ユーザは1つのHANAインスタンス上から複数のアプリケーションにデータベースサービスを提供する形態を取りたいと考える。つまり、複数のアプリケーションそれぞれに、独立したユーザ(テナント)DBを運用したいと考える。

一方で、HANAの高可用性機能であるSystem ReplicationはMDCをサポートする。即ち、複数のユーザDBのプライマリDB→セカンダリDB間の複製、同期、フェールオーバの機能を提供してくれる。ところが、残念なことに、複数テナントDBの内わずか1つのテナントDBに問題があるとHANAシステム全体がフェールオーバをする仕様である。フェールオーバの範囲を、問題があるテナントDBに限ることができない。

詳細な話になるが、System Replicationはプライマリ/セカンダリサイト間のデーベース複製機能である。テナントDBが1つ作られると、indexserverというプロセス、データデバイス、ログデバイスアサインされる。つまり、テナントDBのリソースは独立している。なので、複数のテナントDBのうちの1つがフェールしても、そのテナントDBだけがセカンダリサイトにフェールオーバすればいいような先入観を持ってしまう。

しかし、HANAインスタンス全体の管理がnemaserverという1つのプロセスに任せられてしまっている。しかも、プライマリ/セカンダリの境界を超えて個々のテナントDBを管理することができない、少なくとも、テナントAはプライマリで、テナントBはセカンダリで運用する、ということができない。

結果として、HANAシステムにおいては、複数のテナントDBを運用することはできるが、1つでもテナントDBがフェールするとHANAシステム全体がプライマリからセカンダリへとフェールオーバしてしまう。

これはユーザか見ると、例えば人事システムだけがフェールしても営業システム、製造管理システムその他全部がその影響をうけて一時的なサービス停止またはパフォーマンス低下を被ることになる。

中途半端な実装のような気がするが、SAPはマニュアルの中で「仕様である」と言い切っている。

結局、HANAは、system database + テナントDB1つで運用することになり、マルチテナントとしては使えないことが多い。