vimでビジュアルモードの際にペーストがうまく機能しない

【事象】
ビジュアルモードでペーストを行う際にペーストを行うと無名レジスタの値でペーストしてくれる想定が何故か何も起きない

【原因】
以下の設定をgvimrcに設定しているため、ペーストした時に無名レジスタの値がペーストでヤンクした値に先に塗り替えられてしまい、その値でペーストしていたため

:set clipboard+=unnamed

【対応方法】

  • クリップボードの設定は解除する(デフォルトはset clipboardは空なので:set clipboard~の記述を削除でもOK)
  • クリップボードの値でペーストしたい場合は、事前にF2キーを押すことで無名レジスタの値を書き換える設定を追加する
:set clipboard=
nnoremap <silent> <F2> :let @@ = @*<CR>

【その他】

  • ヤンクは何故か無名レジスタに設定されるタイミングでクリップボードにも書き換わるので逆(無名レジスタクリップボードレジスタ)は用意しなかった
  • ビジュアルモードでSHIFT + INSでクリップボードの値書き換えれたらいいのに、Windows × Vim8.2ではうまくいかない(自分のgvimrcが悪い?)
  • set clipboardの評価タイミングを遅らせる(先にペーストした後にヤンクする動き)事ができたらいいが、なさそうなので上記手段に落ち着いた

マスタリングVim

マスタリングVim

vimの置換する際のcフラグ

【効能】
置換する際に本当にやっちゃっていいかどうかを問いかけしてくれる

【利用例】
:%s/置換前/置換後/gc

【その他】
%はファイル全体を指す
sコマンドは置換を指す
gフラグは対象の文字を全て置換するという意味(デフォルトはヒットした先頭のみ)
【参考リンク】
sedコマンド入門
VIMで置換するときのsコマンドの使い方メモ - Qiita

マスタリングVim

マスタリングVim

[改訂第3版]Linuxコマンドポケットリファレンス

[改訂第3版]Linuxコマンドポケットリファレンス

  • 作者:沓名 亮典
  • 発売日: 2015/06/05
  • メディア: 単行本(ソフトカバー)

22.4 非同期処理と例外処理

コールバック関数内でエラーをキャッチはできるが、非同期処理の外からは非同期処理の中で例外が発生したかは検知できない。
非同期処理の外から例外が起きたことを知るためには、非同期処理の中で例外が発生したことを非同期処理の外へ伝える方法が必要である。
この非同期処理で発生した例外の扱い方に関して、エラーファーストコールバック、Promise、Async Functionがある。

【22.5 エラーファーストコールバック】
ECMAScript 2015(ES2015)でPromiseが仕様に入るまで、非同期処理中に発生した例外を扱う仕様は存在しなかった。
このため、ES2015より前までは、エラーファーストコールバックという非同期処理中に発生した例外を扱う方法を決めたルールが広く使われていた。
エラーファーストコールバックとは、次のような非同期処理におけるコールバック関数の呼び出し方を決めたルールである。
・処理が失敗した場合は、コールバック関数の1番目の引数にエラーオブジェクトを渡して呼び出す
・処理が成功した場合は、コールバック関数の1番目の引数にはnullを渡し、2番目以降の引数に成功時の結果を渡して呼び出す
しかし、エラーファーストコールバックは非同期処理におけるエラーハンドリングの書き方を決めたコーディングルールにすぎなく、仕様ではない。
そこで、ES2015ではPromiseという非同期処理を扱うビルドインオブジェクトが導入された。

例)

/**
* 100ミリ秒未満のランダムなタイミングでレスポンスを疑似的にデータ取得する関数
* 指定したpathにデータがある場合はcallback(null, レスポンス)を呼ぶ
* 指定したpathにデータがない場合はcallback(エラー)を呼ぶ
*/
function dummyFetch(path, callback) {
  setTimeout(() => {
    // /success からはじまるパスにはリソースがあるという設定
    if (path.startsWith("/success")) {
      callback(null, {body: `Response body of ${path}`});
    } else {
      callback(new Error("NOT FOUND"));
    }
  }, 1000 * Math.random());
}

【22.6 Promise[ES2015]】
PromiseはES2015で導入された非同期処理の結果を表現するビルトインオブジェクトである。
Promiseはビルトインオブジェクトであるため様々なメソッドを持つ。
Promiseでは、非同期処理に成功したときの処理をコールバック関数としてthenメソッドへ渡し、失敗したときの処理を同じくコールバック関数としてcatchメソッドへ渡す。
エラーファーストコールバックとは異なり、非同期処理(asyncPromiseTask関数)はPromiseインスタンスを返す。その返されたPromiseインスタンスに対して、成功と失敗時の処理をそれぞれコールバック関数として渡すという形になる。

asyncPromiseTask().ths(() => {
  // 非同期処理が成功したときの処理
}).catch(() => {
  // 非同期処理が失敗したときの処理
});

Promiseインスタンスのメソッドによって引数に渡せるものが決められているため、非同期処理の流れも一定のやり方に統一される。また非同期処理(asyncPromiseTask関数)はコールバック関数を受け取るのではなく、インスタンスを返すという形に変わる。このPromiseという統一されたインタフェースがあることで、さまざまな非同期処理のパターンを形成できる。

[22.6.1 Promiseインスタンスの作成]
Promiseはnew演算子でPromiseのインスタンスを作成して利用する。このときのコンストラクタにはresolveとrejectの2つの引数をとるexecutorと呼ばれる関数を渡す。executor関数の中で非同期処理を行い、非同期処理が成功した場合はresolve関数を呼び、失敗した場合はreject関数を呼び出す。

const executor = (resolve, reject) => {
  // 非同期の処理が成功したときは引数resolveを実行する
  // 非同期の処理が失敗したときは引数rejectを実行する
};
const onFulfilled = () => {
  // resolveが呼ばれた時の処理
}
const onRejected = () => {
  // rejectが呼ばれた時の処理
}
promise.then(onFulfilled, onRejected);

[22.6.2 Promise#thenとPromise#catch]
このPromiseインスタンスに対してthenメソッドで成功時のコールバック関数だけを登録できるが、thenメソッドで失敗時のコールバック関数だけの登録はできるが、そのときはthen(undefined, onRejected)と第一引数にundefinedを渡す必要がある。
Promise#catchはthen(undefined, onRejected)と同じ意味のため、失敗時の処理だけを登録する場合はcatchメソッドの利用を推奨されている。

[22.6.4 Promiseの状態]
Promiseインスタンスには、内部的に次の3つの状態が存在する。
・Fulfilled:resolveしたときの状態
・Rejected:rejectまたは例外が発生したときの状態
・Pending:FulfilledまたはRejectedではない状態、new Promiseでインスタンスを作成したときの初期状態
しかし、この状態をPromiseのインスタンスから取り出すAPIは存在しない。
Promiseインスタンスの状態は作成時にPendingとなり、一度でもFulfilledまたはRejectedへ変化すると、それ以降状態は変化しなくなる。そのため、FulfilledまたはRejectedの状態であることをSetted(不変)と呼ぶ。

[22.6.9 Promise.allで複数のPromiseをまとめる]
Promise.allメソッドはPromiseインスタンスの配列を受け取り、新しいPromiseインスタンスを返す。
その配列のすべてのPromiseインスタンスがFulfilledとなった場合は、返り値のPromiseインスタンスもFulfilledとなり、一方一つでもRejectedとなった場合は、返り値のPromiseインスタンスもRejectedになる。

[22.6.10 Promise.race]
Promise.allメソッドは複数のPromiseがすべて完了するまで待つ処理である。
Promise.raceメソッドでは複数のPromiseを受け取るが、Promiseが一つでも完了した(Settle状態となった)時点で次の処理を実行する。
この新しいPromiseインスタンスは、配列の中で一番最初にSettle状態となったPromiseインスタンスと同じ状態になる。
・配列の中で一番最初にSettleとなったPromiseがFulfilledの場合は、新しいPromiseインスタンスもFullfilledになる
・配列の中で一番最初にSettleとなったPromiseがRejectedの場合は、新しいPromiseインスタンスもRejectedになる

【22.7 Async Function[ES2017]】
ES2017では、Async Functionという非同期処理を行う関数を定義する構文が導入された。
Async Functionは関数の前にasyncをつけることで定義ができる。
async function doAsync() {
return "値";
}
doAsync().the(value => {
console.log(value); //値
});

[22.7.3 await式]
Async Functionの関数内ではawait式を利用できる。
await式は右辺のPromiseインスタンスがFullfilledまたはRejectedになるまでその場で非同期処理の完了を待つ。
そして、Promiseインスタンスの状態が変わると、次の行の処理を再開する。

JavaScript Primer 迷わないための入門書

JavaScript Primer 迷わないための入門書

22.3 非同期処理はメインスレッドで実行される

非同期処理は名前から考えるとメインスレッド以外で実行されるように見えますが、基本的には非同期処理も同期処理と同じようにメインスレッドで実行される。
例えば、setTimeout関数で登録したコールバック関数は、タイマーに登録した時間(10ミリ秒後)よりも呼び出される場合もある。
JavaScriptでは一部の例外を除き非同期処理を並行処理(concurrent)として扱う。並行処理とは、処理を一定の単位ごとに分けて処理を切り替えながら実行することである。そのため非同期処理の実行中にとても重たい処理があると、非同期処理の切り替えが遅れるという現象が発生する。これは、もし非同期処理が別スレッドで行われるならば、自由なデータへのアクセスは競合状態(レースコンディション)を引き起こしてしまうためである。
但し、非同期処理の中にもメインスレッドとは別のスレッドで実行できるAPIが実行環境によっては存在する。例えばブラウザではWeb Worker APIを使い、メインスレッド以外でJavaScriptを実行できる。このWeb Workerにおける非同期処理は並列処理(Parallel)である。並列処理とは、排他的に複数の処理を同時に実行することである。Web Workerではメインスレッドとは異なるWorkerスレッドで実行されるため、メインスレッドはWorkerスレッドの同期的にブロックする処理の影響を受けにくくなる。但し、Web Workerとメインスレッドでのデータのやり取りにはpostMessageというメソッドを利用する必要がある。そのため、setTimeout関数のコールバック関数とは異なりデータへのアクセス方法にも制限がつく。
非同期処理のすべてをひとくくりにはできないが、基本的な非同期処理(タイマーなど)はメインスレッドで実行されているという性質を知ることは大切である。JavaScriptの大部分の非同期処理は非同期的なタイミングで実行される処理であると理解しておく必要がある。

RDS for MySQLでスロークエリーログや監査ログが有効にならない

【事象】
Amazon RDS for MySQLインスタンスを作成する際にログのエクスポートで全てのチェックを入れているのに、スロークエリログや監査ログなどのログが出力されない。

【原因】
Amazon RDS for MySQLの設定をコンソールから行っていたが、
そもそもMySQLのパラメータグループでスロークエリなどの設定を入れてなかった。

【対応方法】
一般ログ、スロークエリログの有効化方法
MySQL を実行している Amazon RDS DB インスタンスのログを有効にしてモニタリングする

監査ログの有効化方法
Amazon RDS MySQL または MariaDB インスタンスの高度な監査を有効にして、CloudWatch にログを公開する

(監査ログ対応方法の別リンク)古い記事ながらもこちらの方が図解もあり分かりやすかった
【新機能】Amazon RDSのMySQLとMariaDBで監査ログに対応。ついでにrdsadminの動作も確認してみた。 | DevelopersIO

【参考リンク】
公式のログ全般に関する説明
MySQL データベースログファイルへのアクセス - Amazon Relational Database Service


【その他】
以下のメッセージが分かって読めば、そりゃそうかーになるけど、もう少し説明欲しい。。。

全般、スロークエリ、監査ログがオンになっていることを確認してください。デフォルトではエラーログが有効になっています。

上記記述より、以下の内容を読み解かないといけない。
・全般(general)、スロークエリログ、監査ログはMySQLのデフォルト値を有効にしないと、ログは出力されないです。
・デフォルトではエラーログだけがMySQLとして出力されるように設定されています。
・あくまでもAmazon CloudWatch Logsで確認できる様にするための設定であって、ここのチェックボックスに設定入れてもMySQL側の設定が有効になってないとログは出力されません。

Amazon Redshiftのクエリ実行しても中止済みにされる

【事象】
エディタでクエリを作成して実行を行った。
Queru resultsではCompletedと表示されるが、Query historyを確認すると状態が中止済みにされてしまう。
また、クエリの中身を確認すると、IAM_ROLE_ARNを指定していた箇所が空文字に置換されてしまっている。

【原因】
クラスタに対するIAMロールのアタッチ忘れ

【対応方法】
左ペインのクラスターより対象のクラスターを選択し、アクション - IAMロールの管理を選択する。
使用可能なIAMロールより指定したいIAMロールを選択し、IAMロールを追加ボタンを押下する。
するとアタッチされたIAMロールのリストに選択したIAMロールが表示されるので、それを確認した上でDoneボタンを押下する。
(IAMロールを追加ボタンを押下せずにDoneボタンを押下してしまったため、いつまで経ってもロール付与できていない事に気づかなかった…)

P256 console.errorとスタックトレース

console.logはメッセージだけなのに対して、console.errorではメッセージと共にスタックトレースが出力される。