2021-11-08

公式ドキュメントを読めというけど

公式ドキュメントだからと言って、考えなしにそのコードを切り貼りしてはいけないんです。っていう私の失敗談。露悪趣味はありません。

Javaの公式ドキュメントとしてJSLのAPI仕様（Javadocと呼ばれたりする）があります。コード例が載ってると「挙動理解するためにとりあえず実行してみようか」とやったりします。

その対象になったのがこのコード。

https://docs.oracle.com/javase/jp/8/docs/api/java/nio/file/FileVisitor.html

Path start = ...
Files.walkFileTree(start, new SimpleFileVisitor<Path>() {
   @Override
   public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
       throws IOException
   {
       Files.delete(file);
       return FileVisitResult.CONTINUE;
   }
   @Override
   public FileVisitResult postVisitDirectory(Path dir, IOException e)
       throws IOException
   {
       if (e == null) {
           Files.delete(dir);
           return FileVisitResult.CONTINUE;
       } else {
           // directory iteration failed
           throw e;
       }
   }
});

簡単に言えば rm -rf {指定したパス} です。なにそれこわい。

コードを読みさえすれば実行したら危ないのはわかるかなとは思うんですが、そういう危なさが判りづらいのがJavaの冗長と言われる所以だと思います。仮にこれを今の自分が実装するなら、deleteがもっと目立つようにするんじゃないかな。ツリーを辿るっていうのと実行する操作は別の関心だと思うし。

教訓としては「公式ドキュメントかどうかに関わらず、コードをコピペで迂闊に試してはいけない」です。ファイル削除だからまだいいけど、どっかにファイル送信するとかだったらえらいことです。流石にそんなコードはまともなドキュメントにはないだろうけど、どこぞのブログとかだったらあっても不思議じゃない。

当時のツイート

f:id:irof:20211108143118p:plain

10年も前の話です。今でも思い出せる程度にはショッキングな出来事でした。Java7リリースは2011-07-28なので、リリース前ですね。人間は失敗して成長するんですよ。失敗したからと言って成長するとは限らないけど。

f:id:irof:20211108180430p:plain

どうにもならなかったから諦めた（諦められたという意味でどうにかはなってるのだけど）。

ついでに新しい話

そういえばJava 18でJavadocのコードスニペットが入ります。 JEP 413: Code Snippets in Java API Documentation です。 {@code} とかは既にありますが、導入の動機となる現在の問題はJEPを参照ください。

2021-10-31

技術から入ってもいいと言う話

思ったこと

システム開発の分野は技術の移り変わりが早く（これも他の分野と比べたことないので「早い気がする」と言うだけなのだけど）、なんらかの成功を収めた企業などの採用しているものがバズワードとなって一気に広まったりします。この時、その技術だけを追ってしまう現象がよく観測されます。だからバズワードになるんだけど。

批判的な意見

バズワードに飛びつくのは往々にしてアンチパターンです。例えば「モノリスからマイクロサービスへ」でも、明確な理由もなくマイクロサービスに飛びつくのは避けるよう書かれています。

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

作者:Sam Newman
オライリージャパン

Amazon

書籍に限らず経験のある人は技術の螺旋を見通し、「この技術は結局のところ重要な課題を解決しない」と示唆する発言をしたりします。強く辛辣な言葉もたまに見かけます。「そこに問題はないんだけどな」とか。

こう言う意見を無邪気に聞いてしまう人は、場合によっては「本質」と言う言葉に振り回されるようになります。「本質はそこじゃないんだ」とか言うものの、見通せているかは危うかったりして。いっちょ噛みで言う「本質」は「完全に理解した」と同義ですし、そんなすぐに本質を見抜けるのなんて卓越した技能を持った人だけです。居ないとは言わないけど、多分その一部ではないんじゃないかな。そして結局何をすればいいのか途方に暮れているようなのも散見されます。

強そうな人の強い発言を目にしてしまうと、その技術を習得することに抵抗を覚えるでしょう。これ自体は自然な気持ちだと思いますが、強い発言は広大な背景を持ってなされるものです。その背景は当人にとって当たり前のことなので、わざわざ語られたりもしません。強い発言は往々にして正しく、説得力があります。経験から発せられる一本筋の通った発言に惹かれるのは当然ですが、その意見を取り入れられる土壌がない状態ではおそらく劇薬でしょう。

技術から入ってもいい

と言うことで、掲題の通り。技術から入ってもいいと思っています。

特定の技術は、特定の課題を解決するための模範解答の一つです。短い記事やブログでなく、ある程度のボリュームの書籍や実用に耐えるツール、テンプレートなどまで昇華された技術には学ぶ価値があります。

対象の問題領域に対して知識が不足している状態で、問題だけを見てコアを掴めるのは一握りのモデリング能力を有した人だけでしょう。少なくとも私にはできない。その問題を捉え、ある側面で切り取ったものが技術だと思います。その特定の技術に精通すれば、解決しようとしている問題領域が、少なくともその技術の実装者が捉えたモデルが習得できます。他の捉え方を身につけるのは、その視点を得てからでも遅くはありません。遅くはないはずです。早い遅いが何で決まるかは知らないけど。

とにかく その技術を最終到達点と認識しなければ大丈夫です。 逆に言えば、その技術があらゆる問題を解決する銀の弾丸（「銀の弾丸」は狼男にしか効かないので、万能ではないと思うんだけど、なんか万能の代名詞として使われますよね。なんでだろ。）やゴールデンハンマーのように捉えたとしたら大丈夫ではありません。先にあげた「批判的な意見」はこれを嗜めるものだと思っています。当人にはそんなつもりもなく、思ったこと言ってるだけだったりしますが。

繰り返します。知らないのならば、技術から入る選択肢を取っても構いません。ただし入り口です。なので「技術から入ってもいい」です。その技術を通して問題の輪郭を掴めたら、同じ問題に対した他の技術で照らし直してみたり、直接問題領域に飛び込んだりしてみることです。次のステップがあることを意識するだけで、だいぶ違うと思います。

特定の技術に固執する癖があるならば、少なくともそこは改めることをお勧めします。固執して突き進めるのは、技術ではなく問題を選べる場合です。卓越した技術があれば問題の方を選べます。問題を選べるようなら、技術への固執云々はたぶん気にしなくていいと思います。私は問題にあった技術を選ぶのが好きなんで、その気持ちはわかりません。

2021-10-26

コード、区分、フラグ、IDと名前。

システム開発ではよくコードや区分、フラグと呼ばれるものを扱います。

これらが混同していたり、曖昧になっていたりすることは多いので、その辺りを整理しておきます。 IDや名前なんかもこの文脈に登場するので、ついでに。

コード

コードはエンコード／デコードできるものです。桁数ごとに意味があったり。一定のルールで読み書きできるのがコードかなと思います。

区分

種類が固定されたコードを、特別に区分と呼ぶことにします。値ごとに意味が決まるので、コードの一種としています。

どんな値が入りうるかわからないものは区分とは呼べません。それは多分コードと呼んだ方がいいです。

フラグ

種類が2つ（on/offやtrue/false）に固定された区分、特別にフラグと呼ぶことにします。 3つ目が出てきたらフラグとは呼べません。それは区分って呼んだ方がいいんだろうなと思います。

フラグと区分の関係を示したいのは、フラグはしばしば増えるからです。削除フラグに入ってる9とか2とかのことです。君はもうフラグじゃない。

ID

IDはidentifier、識別子です。大事なのは一意であることだけです。値の体系は関係ありません。文字として読めなくてもIDはIDです。

体系の決まっているIDはコードの側面も持ちますが、だからと言ってIDはコードではありません。こう言うのは「IDのコード体系」と捉えるのがいいかなと。

コードをそのままIDとして使うこともあります。こう言う文脈ではコードとIDは混同されがちですし、その文脈に閉じれば、同じと看做しても問題ありません。でも広い文脈ではコードとIDは異なります。

IDは識別する範囲内で一意であればいいので、区分はフラグもその範囲内では一意だとかなんとか言えます。それに意味はない気はしますが。

名前、番号

これらは機械ではなく人が主に使用します。名前や番号自体に一意性はありません。読み書きのルールもあるようなないような感じです。

名前や番号として固有の値を付けられることもありますが、しばしばコードやIDがそのまま使われます。「名前で一意になる」は名前がIDの側面を持っている状態です。「シリアル番号から型番がわかる」は番号がコードの側面を持ち、そのコードの一部に区分が使用されている状態です。こう言う時、名前や番号とそれらが混同されがちです。

番号は主に数値で構成され、順序性があったりします。番号を名前として使用することはあるかもしれませんが、名前を番号としては使用しないでしょう。番号は名前よりは一意性を持つ傾向にありますが、一意性はたいして重要じゃないこともあります。番号に一意性が必要であれば、IDを番号に使用するのがいいかと。