AMAgrammar <> PROgrammer

チームでのプログラム開発を行っていると、コードレビューを受け持つ場面が多々出てくる。コードレビューで返す内容は様々で、コードの問題点の指摘や良いコードの評価の他、意図の読めないコードについて質問する事もある。「コードの問題点」も、その深刻さで何段階かに分けられる。単にアルゴリズムが非効率なだけか、バグやセキュリティリスクに繋がるかと言ったような。

そういった個々のレビュー内容についての「温度感」のような物は確かに存在するのだが、それはなかなか伝わりにくい。どのようなレビューコメントも、一見、唯の「コードへの意見表明の文字列」に過ぎないからだ。

そこで、レビュー内容に、その種別を表すラベルを付けようという方法がある。修正必須な物には[must]と付けたり、質問には[ask]を付与したりといった具合に。各々のレビュー内容の頭の数文字を見れば、そのレビューがどのような種別なのかが伝わるという寸法だ。唯のテキストでは、まだ視認性が悪いからという事で、Shield.ioで専用の画像を生成して使用するというアイディアも存在する。

しかし、個人的にはShield.ioを使っても尚、難点が在ると感じる。というか、皆、英語の略やジャーゴンをよく憶えられるね。「IMO」とか「nits」とか、どうにも憶えられない。いきなり言われても「えっと、どういう意味だったっけ？」と思考が止まってしまう。本筋ではない所で脳のリソースを使う手法は避けたい。

もっと視認性と解りやすさを両立した何かが欲しい。何か無いだろうかと考えて、思いついたのが絵文字を使う方法だ。フォントに依っては、文字でありながら様々に着色されているので、通常の文字との区別もしやすい。一種の表意文字と言えるので、その形状からレビューの種別を想像させる事も難しくないだろう。

一先ず、以下のように規定して運用してみている。

もう少しブラッシュアップを行いたい所ではあるが、唯の文字列よりも伝わりやすいのではないだろうか。Shield.ioのような外部のwebサービスに依存せず実現可能な点も長所だろう。

最近「シェルスクリプトの if はパイプ出来る」という事を知った。bashでしか確認していないので、zsh等の別のシェルではどうか分からないが。

よく、コマンドの出力結果を行毎に走査する為に while にパイプするが、条件分岐の構文にパイプを適用するという発想は正直なかった……

# よく有るループの例
cat somefile.txt \
| while read line
do
    # ファイルの各行に対する何らかの処理：ここでは単に出力する
    echo $line
done

if へパイプを繋ぎ以下の用にすると、条件が真の時には then 節のコマンドに、偽の時には else 節のコマンドにパイプを繋いだかのように動作する。勿論、 if から別のコマンドへパイプを繋ぐ事も可能。

echo  "foo
bar" \
| if [[ $var = '' ]]
then
    head -n 1
else
    tail -n 1
fi \
| cat -n

# `var` が空文字列ならば：
# 1    foo
# そうでなければ：
# 1    bar

シェルの特色は「パイプで様々な処理を繋げる事が出来る」点だと分かっているつもりだったが、こんな事も出来たとは……奥が深い。

ノーコード、ローコードというのが最近の流行り（というか、バズワード）のようだ。次のような定義らしい。

ノーコード

（専用ツールを使って）コードを書かずにプログラムを作成する事。

ローコード

（専用ツールを使って）極少量のコーディングのみでプログラムを作成する事。

「いや、そんなん昔から有るじゃん。RPGツクールとか」とも思うが、またRPGツクールのような物はジェネレータと呼んでいた記憶もあるが、それは言ってはいけないのだろう。まぁ所詮はバズワード。

……ところで、既存の、通常のコーディングでプログラムを作成する事は何と言えば良いのだろう？lowの逆だし、ハイコードだろうか？

閑話休題。幾つかノーコード、或いはローコードツールと呼べそうな物を使ってみたので、ノーコード/ローコードツールについての所感を記しておきたいと思う。使ってみたのは次の物：

IFTTT

ノーコード、ローコード両方

Glide

ノーコード

Integromat

ノーコード？

Automate

ノーコード？

不思議な事に、世の中には、何でも正規表現で処理しようという人種が居る。例えばHTMLやJSONのパース処理を正規表現を駆使してやろうとする。

何故、わざわざ正規表現を使おうとするのか。既に誰かが作ったパーサライブラリが在るというのに、そういった物は頑なに使おうとはしない。あくまで正規表現を使って何とかしようとする。

既存のライブラリを使った方が良い点として：

• なんと言っても、正規表現は容易に「暗号文」化する。複雑な構造のデータをパース出来る、複雑な構造の正規表現を書いた当人は大いに満足しているのかもしれないが、後からそれを「解読」する人間の身にもなってほしい。

• 枯れている。少なくとも、今この瞬間に書かれた、その正規表現よりは枯れている。つまりバグが混入している可能性は、今書かれたソレよりも格段に低い。

• 必要な処理を実装する時間も短くて済む。例えば、「HTMLコード中の『foo』というIDを持つ要素の子孫要素として存在する『bar』クラスの要素の直接の子要素の最初のテキストノードの内容を全て拾え」、という処理が在ったとして、「任意のIDの要素を取得」「任意の要素の子孫要素を全て取得」「任意のクラスを持つ要素を全て取得」「テキストノードの内容を取得」なんて処理は、パーサライブラリが既に用意しているだろう。今からその正規表現を書く時間は無駄である。

そもそもの話として、正規表現は万能ではない。HTMLやJSONのような、「入れ子になった構造」を処理できない。なので、そういった物を処理しようとして書いた、その正規表現には、100%バグが潜んでいる事になる。今、受け取っているデータは処理できたとしても、一寸だけ内容の変わったデータが来ると途端に木偶と化す可能性が在る。詳しくは、例えば 「Leo's Chronicle: 正規表現に見切りをつけるとき」 等を参照。

正規表現で何でもパース出来ると思うな。悪い事は言わないから、良いから黙って専用のパーサライブラリを使え。

Windows10上に本物のLinux環境を構築できる Windows Subsystem for Linux、略してWSL。現状、初代と vertion 2 の新旧2つが在るが、その新しい方、WSL2について。

これは Linux Advent Calendar 2020 の14日目の記事である。13日目はSumi-Sumiさんの 「windows in ArchLinuxで無線フルトラする」だった。「フルトラ」って「フルトラッキング」の略なのかな……VR分かんないマンなので、よく分からない。

Linux Advent Calenar、今回、（ノリとイキオイで）初めて参加したのだが、13日目迄の記事のレベルが総じて高い。ヤバい……昨年迄の分を見てレベルを確認しておけば良かった……と思っても既に後の祭り。小ネタで申し訳ないが、ちょっとしたティーブレイクという事で、ここは一つ……

閑話休題。*nix系のOSには、Windowsには無い素敵な機能が在る。そう、shebangである。ファイルの1行目に、#!に続けて、そのファイルの内容を解釈するプログラムのパスを書いて、実行パーミッションを付与しておけば、宛ら実行可能バイナリファイルのように振る舞ってくれる。

shebangの挙動は、 Git for Windows に付属しているBashでも再現されている。 Git Bash 上ではLinuxのファイル階層が再現されているので、Windows上でBashのスクリプトを開発する事も、まぁ可能だ。

さて、先日、 Git Bash 上で動作確認を行ったBashスクリプトファイルをLinux上に持っていくと、エラーが発生するという現象に遭遇した。エラーメッセージは次の通り。

-bash: ./script.sh: /bin/bash^M: 誤ったインタプリタです: そのようなファイルやディレクトリはありません

私の現在の勤め先は、コードレビューを行う、そこそこマトモな開発体制なので、私も他人の書いたコードをレビューする事が有る。先日レビューしたコードに「コレクションクラスのオブジェクトをコレクションしたコレクションクラスのオブジェクト」が含まれていたので、それは拙いと指摘した。ここでいう「コレクションクラスのオブジェクトをコレクションしたコレクションクラスのオブジェクト」が何を指しているかと言うと、例えばList<List<String>>だとかList<Map<String, String>>だとか、その手の型のオブジェクトの事である。これが適切なケースも在るが、大抵はそうではない。より内側のコレクションクラスは、それを表現する独自のクラスを定義出来る事が大半だし、そうした方が読み書きしやすくなる。

これは、過去に私自身が実際に痛い目を見た事でも在るが、別のプログラマーが体験した事でもある。何故そう言えるかと言うと、そのプログラマーが教訓として文章化した物を読んだ事が有るからだ。レビューの指摘事項の根拠の補強として提示しようと思ったのだが、困った事に、それが誰が何処に書いた文章なのかサッパリ思い出せない。適当なキーワードを推測してググってみても見つからない。一言一句、正確に憶えているならばフレーズ検索で探し出せるのかも知れないが、それは無理な注文というものだ。

こういったページを探し出す上手い手段というのは何か無いのだろうか……

覚書を兼ねて。

標準入力からの内容を元に、任意のコマンドを実行できるxargsコマンド。例えば、以下のような使い方が出来る。

# `man xargs` で確認できる1番最初の用例より。
# /tmp以下から "core" という名前のファイルを再帰的に検索し、それを削除する。
find /tmp -name core -type f -print | xargs /bin/rm -fa

ところで、この例では、ファイル名に空白記号が含まれていた場合、上手く動作しない。空白が語と語の区切りと見做されるからである。

# 先と同じ例で、ただし対象となるファイル名が "have whitespace" であった場合。
# 期待に反してファイルは消えない。
find /tmp -name 'have whitespace' -type f -print | xargs /bin/rm -f

何故ならば、xargsで実行する/bin/rmは、実質的には /bin/rm -f have whitespace となり、「have」と「whitespace」と2ファイルを消す操作となるからである。機械的に語が追加された結果、語の中の空白文字が、コマンド引数の区切り空白と見做されてしまう為である。

こういう場合どうすればいいか? 回答の1つは、xargsへの入力を明示的にクォートする事であるようだ。

# `sed` で明示的にクォートする事で、「空白を含む1語」である事を明示する。
find /tmp -name 'have whitespace' -type f -print | sed -e "s/^.*$/'&'/g" | xargs /bin/rm -f

sedがキモい……xargs側で面倒を見てほしい気がする……

別解としては、xargsへの入力をNULL文字区切りにする方法が在る。ただし、findのような、NULL文字区切りで出力できるコマンドを使用する時に限られる。例えばlsでは無理。

# NULL文字を区切りとして使う＝空白文字は区切りと見做されない。
# `find` の `-print0` でNULL文字区切りで出力し、
# `xargs` の `-0` で、入力がNULL文字区切りである事を知らせる。
find /tmp -name 'have whitespace' -type f -print0 | xargs -0 /bin/rm -f

諸事情でJavaScript無しでハンバーガーメニューを実装する必要が出た。つまり、メニュー表示用アイコンを準備し、それがクリックされた時にメニューを表示するという実装。JS無しですってよ奥様。いやいや無理だろ。

ダメ元で調べてみると……いやぁ何事もググってみるもので、CSSのみでマウスクリックを検知し、ページに変化を起こさせるサンプルが見つかった。

新年明けまして御目出度う御座います。今年は、もうちょっと、頻繁にblog更新できると良いなあ。

プログラミング書き初めというのを思いついた。既に誰かやってそうではあるが。

一先ず思いついたルールは以下の通り。

1. 「kakizome」リポジトリをGithub等で公開し、毎年新しい書き初めを追加する。
2. 毎年、初めて触る 言語 or ライブラリ or パラダイム を使う。
   どうせなら新しい物に触ってワクワクしようぜ!という趣旨。
   「条件分岐なしにFizzBuzzを書く」みたいな、トリッキーな記法に挑戦するでも良いかもしれない。初めて書く方法であれば。
3. 出来れば3が日以内に行う。
4. 推奨は「 『A Happy New Year (西暦年数)!』 というテキストを出力する」プログラム。
   理由は、 「hello world」 系のプログラムであれば、様々な環境で書ける事が期待できるから。
   ネットワークライブラリであれば「サーバーから取得した 「A Happy New Year (西暦年数)!」 という文字列をクライアント側で表示」とか、グラフィック系であれば「直線や曲線で、お題の文字列を描画」などでも良い。

という訳で、書き初め。TypeScriptでやってみた。

kakizome/2017 at master · AmaiSaeta/kakizome

何も、後ちょっとで3が日が終わる今、公開しなくても良いじゃんとも思うが、思いついたのが今日の昼過ぎで、他の用事も片付ける必要があったからね。仕方ないね。

他の人も同じように書き初めプログラムを公開して、ああこんな 言語 or ライブラリ or パラダイム があったのねみたいに影響を与えあえれば良いなぁと。 「hello world」 系のプログラムであれば、そう長い物にはならないだろうし。来週は土曜から月曜（成人の日）まで3連休の人も多いだろうし、いろんな人が取り組んでみてくれると嬉しいな。

まぁ、この試みが続くかは神のみぞ知る。何せ次は1年後だから……