四種類ある。全部動作は同じでshallow copy。
arr = [1, 2, [3]] // 下記全部一緒。三つ目の要素だけ参照型なので共有される。 arr2 = arr.slice() arr3 = arr.concat() arr4 = [...arr] arr5 = Array.from(arr)
個人的にはArray.from()が一番しっくりくるかな。でもタイプ量は一番多い…
参考
Google Nest Camを買ってベビーモニターにしている
Pixel 6を買ったときにGoogle Storeのクレジットが11,000円分もらえたのだが、如何せん欲しいものがない。どうしたものかと思っていたが、Google Nest Camを買ってベビーモニターとして使えないかという案を思いついた。そして実行してみた。買ったのはこれです。
（Amazonでも売ってるのね）
まだ使い始めて一週間くらいだけど、普通に使えます。良いです。部屋真っ暗でも映るし、物音も聞こえるし、人の動きを感知して通知してくれるのも割と便利。
どう使っているのかというと、まず本体は寝室に固定。下の子（0歳）を寝かしつけて寝室に置いたあと、リビングに戻ってきて前の携帯（Galaxy A10）でGoogle Homeアプリを開き、カメラをオンにして監視。泣いたりモゾモゾ動いたら様子を見に行く。という感じ。これがあることにより、夫婦共にリビングにいても安心感がある。ベビーモニターの有無で夜の快適さがだいぶ違うので、導入してよかった。
今のところ特に不満はないし、似たような境遇（Google Storeのクレジットが余っているetc）な方にはおすすめ。
他社のベビーモニターも結構高かったりするので、クレジットとかなくても普通にアリかと思います。
Vacuous Truth という概念を知っておくとプログラミングに（ちょっとだけ）役に立ちそう
TL;DR
空のコレクションに allMatch() 的な判定をするとtrueになるぞ！気をつけろ！
背景
あるリストの全ての要素がとある条件を満たすどうかを返すメソッドがあり、 allMatch(何かしらの条件) した結果をbooleanとして返すという実装になっていた。このメソッドを利用しようとした時、ふと頭に疑問が湧いた。これって、リストが空だったら結果はどうなるんだっけ…？
というわけでREPLを開いてちゃちゃっと確認してみたところ、結果はtrueであった。
# 空のリストに対して、「全ての要素が奇数である」という判定をしたら true になる…？ jshell> List<Integer> list = List.of(); list ==> [] jshell> list.stream().allMatch(v -> v % 2 != 0); $3 ==> true
直感的にはfalseが返ってくるのかと思った（だって奇数は含まれてないし！）ので、何故こうなるのか、他の言語でも同じなのかなどを調べてみた。
プログラミング言語における実装
Java
その時使っていたのはJavaだったので、Stream APIのallMatchメソッドの仕様を確認したところ、下記のように書いてあった。
If the stream is empty then true is returned and the predicate is not evaluated.
はい。普通に載ってましたね。公式ドキュメントちゃんと読めって話ですな…。でも、なぜそうなるのかは書いていない。なぜなんだろうか。
Ruby
次にRubyのArray#all?の仕様を調べてみると、arrayが空の場合については特に書いていない…と思いきや、例のところにこっそり（？）載っていた。
p [].all? {|v| v > 0 } # => true
trueということなので、JavaのallMatchと同じ挙動のようだ。しかしこれ、文章で説明書いといてくれた方が親切な気もするな。
Rust
もう一例くらい欲しいなと思ってRustの iterator::all の仕様を調べたところ、
An empty iterator returns true.
とあった。やはりtrue。
何故なのか
3例も調べたので、まあどのプログラミング言語でも同じ結果になると思ってよさそう1。ということは、なぜ true になるのかちゃんとした理由があるに違いない。
Vacuous Truth
どうやらこのような挙動は論理学でちゃんと定義されており、"Vacuous Truth"と呼ばれているらしい。対応する日本語はなさそうなので、Wikipediaも英語版しかない。
ここで書いてある例としては、「ある部屋にある全ての携帯電話は電源がオフである」という命題があった時、その部屋にそもそも携帯電話がなかった場合、この命題は真になるというもの。
ちなみに「ある部屋にある全ての携帯電話は電源がオンである」という命題もまた真になり、また「ある部屋にある全ての携帯電話は電源がオンであり電源がオフでもある」という支離滅裂な命題もまた真になる。このような命題は部屋が空であるときにしか真にならないため、"vacuously" trueと呼ばれているそうだ。へー。あ、vacuousは「空虚な」みたいな意味です。
で、結局なぜこの場合trueになるの？というところですが、「論理包含」というページ内の例に説明がありました。
P が偽ならば、Q の真偽にかかわらず「P ならば Q」が真である ということらしく、直感に反している感はあるけどちゃんと説明可能とのこと。辞表の例が一番わかりやすそうな気がしたので引用します。
ある人が「この仕事が失敗したら辞表を出す」と言ったとしよう。この言葉が嘘となるのは、仕事が失敗したにもかかわらず辞表を出さなかった場合のみである。仕事が失敗して辞表を出したならば約束を守ったのであるし、仕事が成功して（失敗せず）かつ辞表を出さなかったならば、やはりその人は嘘を言わなかったことになる。仕事が成功したにもかかわらず（何か他の理由で）辞表を出した場合も、やはり嘘を言ったとはみなされないであろう。すなわち、先の宣言では仕事が成功した場合のことは何も言っていないのであるから、辞表を出そうが出すまいが本人の自由である。
なるほどなー。元の問題に立ち返ってみると、そもそも「コレクションに要素が存在するならば」という条件Pがあると考えればいいのかな。ここが偽になったらQがなんであれ真になると。
結論
ちゃんと数学の勉強をしている人なら当たり前に知っていることなのかもしれないが、Vacuous Truthという概念があり、これはプログラミングにおける「空のコレクションに対して全要素の条件マッチをするとtrueが返る」という実装に反映されている。概念レベルで一度理解してしまえばこの挙動を忘れることはないと思うので、Vacuous Truthについて理解しておくことはプログラマにとって一定の利益がある。ので理解しておきましょう。ということが言いたかったのでした。
余談
ちなみにですが、allMatchではなくanyMatchの場合、結果はfalseになります。Rubyならany?、Rustならany。いずれもfalse。何故こうなるのかはちょっとよく分かってません。
若干罠っぽい（なんで一緒じゃないの？直感的じゃない…と思いがちな）挙動ですが、allとanyで結果が逆になると考えれば忘れなさそうです。
-
追記: よく見たら Vacuous Truth のWikipedia ページにJavaScriptとPythonの例が載っていた。もちろん結果は true↩
nuxt-create-appしてnpm run devしたらerror:0308010Cになる件
タイトルのまんまですが、nuxt-create-appで適当にプロジェクトを作ってnpm run devしたらいきなり下記のエラーになった。Nodeのバージョンは 17.5.0。
Error: error:0308010C:digital envelope routines::unsupported ...(中略) opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ], library: 'digital envelope routines', reason: 'unsupported', code: 'ERR_OSSL_EVP_UNSUPPORTED' }
なんだかOpenSSL関連っぽい感じ。とりあえずエラーメッセージでググって上から10個くらい記事を読んでみると、Node 17 からOpenSSL 3 が使われるようになり、Webpack 4 内部で使ってるハッシュアルゴリズム (md4?) がサポートされなくなったのが原因らしい。package-lock.jsonを見ると"webpack": "^4.46.0"だったのでなるほどという感じ。ちなみにWebpack 5 でもダメだとか。
ちゃんと調べてないけど、下記のコメントを見る限り Webpack 6 ではハッシュアルゴリズムを変えてくれるらしい。
Webpack 6 が出てNuxtのdependencyが更新されるまでの間どうすりゃいいのよ？というと、
- node起動時に
--openssl-legacy-providerをつけるか、export NODE_OPTIONS=--openssl-legacy-providerで環境変数にセットしておく - webpackの設定に
output.hashFunction: "xxhash64"を追記する - LTS version のNodeを使う (現時点だと 16.14.2)
のどれかでいけるらしい。とりあえずNodeのバージョンを 16.14.2 に下げたら動きました。なかなか難儀な話だなぁ。
教訓としては、特にこだわりがなければ日頃からLTS使っとけってところでしょうか。
参考
Dockerコンテナが立ち上がらず no space left on device になるからdocker system pruneしたけどダメ
ローカル開発で使っているデータベース用のコンテナが立ち上がらず、no space left on deviceと表示されるのであーノースペースがレフトなんだなと思ってdocker system pruneをノールックで実行というのを雑にやっていたのだが（ローカルに失って困るイメージとかコンテナとかないだろうということで）、これをやっても同じエラーが出続けるので困った。
ちゃんと調べてみると、Docker 17.06.1 以降ではdocker system pruneでボリュームも削除するには--volumesフラグが必要になると書いてあった。全然知らなかった…。ちゃんと最新情報を追わないといけないな。
というかよく考えたら、ボリューム消したいだけならdocker volume pruneした方がいいよなあ。これからはそうしよう。
JavaのUnboxingでNullPointerExceptionが出てほしくない
Java初心者なので、戻り値の型がLongなAPIを使いたいけどnullとか嫌だからlongにしちゃおーといって適当にAuto boxingしたらNullPointerExceptionが出てしまった。こんな感じ。
// SomeLibrary#count の戻り値の型はLong long count = SomeLibrary.count(); // => NullPointerException
あれ、そうだっけ？nullだったら勝手に0lとかになってくんないの？と思ってJShellでも試してみる。
jshell> Long wrapper = null; wrapper ==> null jshell> long primitive = wrapper; | 例外java.lang.NullPointerException | at (#2:1)
まあそもそもラッパークラスになってる時点でnullを許容する必要があり、nullであるという状態は何かしらの意味を持っている（はず）のだからちゃんとnullの時に対応するコードをかけということだとは思うけれども、それでもなおnullとかいらねーよというときはある。皆さんもあるでしょう。多分。結局Optional使ってこんな感じで書けばいいということだろうか。
jshell> long primitive = Optional.ofNullable(wrapper).orElse(0l); result ==> 0
Optionalがなかったら一旦Long型の変数に入れてからif文でnullチェックして云々みたいなことが必要そうなので、Optionalのおかげで少しは書きやすくなっているということだろうか。しかし、本質的には明示的なnullチェックとそんなに変わらない気がするし、どうせだったらnull合体演算子とかエルビス演算子みたいなの導入してくんないかなあ。long primitive = wrapper ?: 0l とかで書ければ楽なんだけどねえ。
はじめて学ぶソフトウェアのテスト技法 を読んだ
なぜ読もうと思ったか
ソフトウェアテスト系の書籍をあまり読んでこなかったのでちゃんと読もうと思った。ので、適当に評判が良さそうなやつを買ってみた。
どのような本か
本書は、ソフトウェアテストの必修技法を満載した初心者にもわかりやすい解説書です。最少のテストケースで最大の効果をあげるためのツールを満載した、小さいけれどすごい本。
らしい。（Amazonの紹介ページからのコピペ）
確かにそんな感じはする。が、後半はちょいちょいやり過ぎ感ある（※個人の感想です）ので、本当の初心者は前半を頑張って読んで後半はサラッと流すくらいでいいかもしれない。
書評というか感想
確かに初心者でもわかりやすく色々書いてある本だという印象。ただし基本的にテスト担当者が開発者とは別に居ることを前提に書かれているので、基本的に開発者自身がテストも全て実施するような体制だと若干ピンとこない部分はあるかもしれない。特にSection III。まあそういう場合は流し読みすればいいと思う。
知らないことも結構あったし、知っていることも「あ、これってこういう名前なんだ〜へ〜」とか「こういう分類があるんだ、なるほどなー」みたいな感じで楽しく読めた。せっかくなので印象に残ったところを適当にメモします。
まずテストのレベル。本書では単体テスト、統合テスト、システムテスト、受け入れテストという４つのレベルに分類されている。経験上、テストの分類って統一するのが難しいというか会社やチームによって全然違うと思うのだが、この４定義は結構分かりやすい気がするので、初心者の方はとりあえずこれをベースに覚えておいてもらえばいいのかもしれない。
Section I ではテスト技法１つにつき１章という感じの構成になっている。せっかくなのでそれぞれについて感想を書きます。
同値クラステスト（同値分割）、境界値テスト、デシジョンテーブルあたりはソフトウェア開発者なら漏れなく知っておいてほしい技法という感じなので特にコメントなし。知らない人はこの本読みましょう。
次にペア構成テストというのがあって、「すべてのペアをテストする」ということらしい。こいつは簡単そうに見えて結構大変では…？と思って読み進めていたら、直行表を作ってすべてのペアを網羅するサブセットを探す的な手法が出てきてこれがまあまあややこしかった。でも変数が多くてテストケースの作成が大変な時は一度やってみていいかもしれないなあ。
状態遷移テスト、ドメイン分析テストはそういう名前があるとは知らずにやっている人が多そうな感じ。気合い入れてテスト書く時はこういうことやるよなー、的な。でも名前があるとテストケースを考えるときに思いつきやすくて便利そう。
ユースケーステストはいわゆるE2Eテストとしてやってる人は多そう。フォーマットという意味では途中で出てくるテンプレートが参考になりそうだと思った。今度使ってみようかな。
ここまででSection I 終わり。Section II ではホワイトボックステストということで制御フローテストとデータフローテストの二種類の技法が紹介されている。
制御フローテストの方にはテストカバレッジの定義の話があるので初学者には是非読んでもらいたい。データフローテストの方は正直ちょっとピンと来ないかなあ。うーん。こういうのはコンパイラにチェックしてもらいたい気持ち。
Section III はスクリプトテストと探索的テスト。そういう名前だったのかお前ら！という感じ。とにかくなるべく早い段階でテストケースをしっかり作ってその通りにやるのがスクリプトテスト、逆にテストを実行しながらやるべきことを考えていくのが探索テスト。この二つを組み合わせてやりましょうねーみたいな話。なるほどねえ。
第１４章「テストの計画」には普通に良いことが書いてあったので、一部を下記に引用します。
「計画は、手段と目的をたえず調整し続けるという点で、連続的なプロセスである。また、計画は連続的な調整および改善であるという点で、進化的なプロセスとみなすべきである。
なんかもう、テストに限った話じゃないですよね。素晴らしいです。思わず敬語になっちゃうレベル。
Section IV は補足的な感じだけど、１５章にある色々な分類はちょっと興味深い。どこまで意味があるかはちょっとわからないけど、ISO 9126とか一回読んでみようかな…と思ったら有料かあ。うーむ。
最後にSection Vがちょろっとだけある。ちょっと短すぎて引用したら中身全部載せるのと同義になってしまいそうなのであえて引用しないでおきますが、真理が書いてました。普遍の真理。要は、本読むだけじゃなくてちゃんと実践しろってことですね。
そんなこんなでダラダラ感想を書いたわけですが、文章も読みやすいしなかなか良い本だと思う。ソフトウェア開発初学者にオススメできる良書だし、僕みたいにテスト系の本あんまり読んでないなーという人の入りとしてはとても良いと思いました。
