削除する前に削除対象を確認する

データの誤削除を防ぐための作業テクニックとして、「削除する前に削除対象を確認する」というものがあります。
本番環境での作業や、試験日程がシビアな総合テストの作業等、ミスが許されない場合に特に有効です。

今回の記事では、SQLの例とUNIX/LINUXの例を挙げて紹介します。

【SQLの例】

事前にdelete文と同じ条件でselect文を打つことで、delete文のミスに事前に気付くことができます。

例えば、商品テーブルに以下のようなレコードが登録されているとします。
select * from 商品;

このテーブルについて、引き渡し先が登録されているレコード(NULLではないレコード)を削除しようとした場合、以下のようなSQL文を作成します。
delete from 商品 where 引き渡し先 is not null;
しかし、仮にここで条件文のnotを忘れると、逆に引き渡し先が登録されていないレコード(NULLのレコード)を削除してしまいます。

そこで、同じ条件で事前にSELECT文を発行します。
select * from 商品 where 引き渡し先 is not null;
このselect文を発行することで、事前に消えるレコードを見ることができます。
今回の例では以下のレコードが消えることを確認できます。

【UNIX/LINUXの例】

rmコマンドを-fオプション無しで対話式で削除するにはファイル数が多すぎる場合において、事前にrm -fコマンドと同じ対象にls -lコマンドを発行することで、削除対象のミスに事前に気付くことができます。

例えば、dir1というディレクトリを削除したい場合、いきなりrm -rfコマンドを発行するのではなく、事前にdir1に対してls -lコマンドを発行します。
(下位ディレクトリも確認したい場合は、ls -lRコマンドを発行します)

これで事前にどのようなファイルが削除されるのかを確認することができるため、問題がなければ「ls -l」を「rm -rf」に置き換えて実行します。

機械学習を始めるきっかけになる(かもしれない)プレゼン資料

AI(機械学習)には興味があるけど何から始めたら良いのかわからない、という方向けに、AIプログラミングを始めるきっかけになればと思って作ったプレゼン資料です。
「用意されているライブラリを使えば、統計的な分析を簡単に始められる」ということが伝われば幸いです。

https://cyzennt.co.jp/blog/wp-content/uploads/2019/04/eb390e799071b7b4da27b51d4ec2dc66.pdf

サクラエディタのマクロをバッチファイルで複数ファイルに対して実行

サクラエディタのマクロは、コマンドラインから実行することが可能です。
これを利用し、Windowsバッチを用いて複数ファイルに対してマクロを実行することが可能です。

例としては以下の通りです。

【フォルダ構成】

【ファイルの中身】

・CRLF→LF.mac

・CRLF→LF.bat

【処理結果】

C:\tmp\work の直下のファイルについて、改行コードの置換が一括で行われる。
(WindowsのCRLF→UnixのLF)

サクラエディタで使える便利な正規表現3選

システムの開発・保守・運用の作業を行うにあたって、サクラエディタを使って置換やgrepを行うことは少なくないと思います。
今回は、置換やgrepで使える便利な正規表現を3つ紹介したいと思います。

1.全角文字の指定

サクラエディタの正規表現では、文字コードを16進数で指定することが可能です。
そこで、以下のように指定すると、「全角文字1文字」を表現することができます。
(正規表現に「dregonig.dll Ver.3.06 with Onigmo 5.15.0」を使用している場合)

[^\x00\x00-\x7F\x00]

「\x00\x00-\x7F\x00」はASCIIコードで定義された半角文字を意味しているのですが、それを[^…]の形式で否定することで「全角文字1文字」を表現しています。

2.参照機能

置換で使える機能です。
これは、ヒットした文字列を置換後に参照できるという機能で、この機能を使用することで文字の入れ替えや柔軟な置換条件の指定が可能になります。

置換前の文字列の指定で「()」で囲った部分については「${1}」で参照できます。
「()」で囲った部分が複数存在する場合は、2つ目の「()」は「${2}」、3つ目の「()」は「${3}」…といった形で参照できます。

例を挙げると、以下のように使用できます

・置換前の文字列

hoge,fuga,piyo

・置換の指定

置換前…(.+),(.+),(.+)
置換後…${2},${3},${1}

・置換後の文字列

fuga,piyo,hoge

3.指定した文字列を含まない行の抽出

これはgrepで使用できる表記方法で、Linuxのgrepの-vオプションと同じように指定した文字列を含まない行を抽出することができます。
以下のように表記することで、それが可能になります。
(hogeは任意の文字列を示す)

^((?!hoge).)*$

詳しい説明は割愛しますが、正規表現の表記法の一つである「否定先読み」を応用した書き方となっています。

デシジョンテーブルを使用したテストケース設定

条件分岐が複雑な場合、テストケースの設定に漏れが発生して、テストでバグを洗い出しきれなくなることがあります。
そのような場合は、デシジョンテーブルを書いてテストケースを明示的に洗い出すのが有効になります。

デシジョンテーブルの書き方について、例を挙げて説明していきます。
今回も、在庫管理システムの在庫発注処理の例を使用します。
発注するべき条件(在庫切れ、若しくは人気上昇)を満たしている時に、発注関数を呼び出し、発注量や発注日等を計算するという仕様を想定します。
また、最後の発注日から3日以上経過しないと新たに発注できない、という仕様を想定します。
フローチャートは以下の通りです。

この例の場合、以下のようにデシジョンテーブルを書くと、これらの条件からテストケースを洗い出すことができます。
「入力」欄に条件の組み合わせを、「出力」欄に各々の条件の組み合わせの結果を書きます。

発注経過日のように境界値分析が必要になる箇所は、「境界値以下(代表値2)」「境界値と同じ(3)」「境界値を超える(代表値4)」の3パターンを洗い出した方が良いです。
分岐を網羅するだけであれば「境界値以下」「境界値と同じ」の2パターンのみで十分なのですが、コーディングの誤り(IF文の「≧」を「=」としてしまう誤り)で境界値と同じ場合のみ条件が真になるという実装になってしまっていることがあるため、上記3パターンでテストを行うのが無難です。
(本当にこのような誤りを見たことがあります)

また、今回は12パターンのテストケースを洗い出していますが、テストケースが多すぎてテストする時間が取れない場合は、デシジョンテーブルを見ながら不要なテストパターンを抽出するのが有効となります。
今回の例で言うと、発注経過日が3日未満の場合については、在庫切れフラグや人気上昇フラグが発注有無に関与しないことを確認できれば良いので、テストケース2やテストケース3は削っても問題ないでしょう。発注経過日が3日を超える場合についても、前述のようなコーディング誤りがないことを確認できれば良いので、テストケース10やテストケース11は削っても問題ないと思います。