yak shaving life

遠回りこそが最短の道

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 APIallMatchメソッドの仕様を確認したところ、下記のように書いてあった。

If the stream is empty then true is returned and the predicate is not evaluated.

はい。普通に載ってましたね。公式ドキュメントちゃんと読めって話ですな…。でも、なぜそうなるのかは書いていない。なぜなんだろうか。

docs.oracle.com

Ruby

次にRubyArray#all?の仕様を調べてみると、arrayが空の場合については特に書いていない…と思いきや、例のところにこっそり(?)載っていた。

p [].all? {|v| v > 0 }           # => true

trueということなので、JavaallMatchと同じ挙動のようだ。しかしこれ、文章で説明書いといてくれた方が親切な気もするな。

docs.ruby-lang.org

Rust

もう一例くらい欲しいなと思ってRustの iterator::all の仕様を調べたところ、

An empty iterator returns true.

とあった。やはりtrue

doc.rust-lang.org

何故なのか

3例も調べたので、まあどのプログラミング言語でも同じ結果になると思ってよさそう1。ということは、なぜ true になるのかちゃんとした理由があるに違いない。

Vacuous Truth

どうやらこのような挙動は論理学でちゃんと定義されており、"Vacuous Truth"と呼ばれているらしい。対応する日本語はなさそうなので、Wikipediaも英語版しかない。

en.wikipedia.org

ここで書いてある例としては、「ある部屋にある全ての携帯電話は電源がオフである」という命題があった時、その部屋にそもそも携帯電話がなかった場合、この命題は真になるというもの。

ちなみに「ある部屋にある全ての携帯電話は電源がオンである」という命題もまた真になり、また「ある部屋にある全ての携帯電話は電源がオンであり電源がオフでもある」という支離滅裂な命題もまた真になる。このような命題は部屋が空であるときにしか真にならないため、"vacuously" trueと呼ばれているそうだ。へー。あ、vacuousは「空虚な」みたいな意味です。

で、結局なぜこの場合trueになるの?というところですが、「論理包含」というページ内の例に説明がありました。

ja.wikipedia.org

P が偽ならば、Q の真偽にかかわらず「P ならば Q」が真である ということらしく、直感に反している感はあるけどちゃんと説明可能とのこと。辞表の例が一番わかりやすそうな気がしたので引用します。

ある人が「この仕事が失敗したら辞表を出す」と言ったとしよう。この言葉が嘘となるのは、仕事が失敗したにもかかわらず辞表を出さなかった場合のみである。仕事が失敗して辞表を出したならば約束を守ったのであるし、仕事が成功して(失敗せず)かつ辞表を出さなかったならば、やはりその人は嘘を言わなかったことになる。仕事が成功したにもかかわらず(何か他の理由で)辞表を出した場合も、やはり嘘を言ったとはみなされないであろう。すなわち、先の宣言では仕事が成功した場合のことは何も言っていないのであるから、辞表を出そうが出すまいが本人の自由である。

なるほどなー。元の問題に立ち返ってみると、そもそも「コレクションに要素が存在するならば」という条件Pがあると考えればいいのかな。ここが偽になったらQがなんであれ真になると。

結論

ちゃんと数学の勉強をしている人なら当たり前に知っていることなのかもしれないが、Vacuous Truthという概念があり、これはプログラミングにおける「空のコレクションに対して全要素の条件マッチをするとtrueが返る」という実装に反映されている。概念レベルで一度理解してしまえばこの挙動を忘れることはないと思うので、Vacuous Truthについて理解しておくことはプログラマにとって一定の利益がある。ので理解しておきましょう。ということが言いたかったのでした。

余談

ちなみにですが、allMatchではなくanyMatchの場合、結果はfalseになります。Rubyならany?、Rustならany。いずれもfalse。何故こうなるのかはちょっとよく分かってません。

若干罠っぽい(なんで一緒じゃないの?直感的じゃない…と思いがちな)挙動ですが、allanyで結果が逆になると考えれば忘れなさそうです。


  1. 追記: よく見たら Vacuous Truth のWikipedia ページにJavaScriptPythonの例が載っていた。もちろん結果は 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 ではハッシュアルゴリズムを変えてくれるらしい。

github.com

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使っとけってところでしょうか。

参考

itsmycode.com

stackoverflow.com

github.com

github.com

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フラグが必要になると書いてあった。全然知らなかった…。ちゃんと最新情報を追わないといけないな。

docs.docker.jp

というかよく考えたら、ボリューム消したいだけならdocker volume pruneした方がいいよなあ。これからはそうしよう。

JavaのUnboxingでNullPointerExceptionが出てほしくない

Java初心者なので、戻り値の型がLongAPIを使いたいけど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。まあそういう場合は流し読みすればいいと思う。

知らないことも結構あったし、知っていることも「あ、これってこういう名前なんだ〜へ〜」とか「こういう分類があるんだ、なるほどなー」みたいな感じで楽しく読めた。せっかくなので印象に残ったところを適当にメモします。

まずテストのレベル。本書では単体テスト、統合テスト、システムテスト、受け入れテストという4つのレベルに分類されている。経験上、テストの分類って統一するのが難しいというか会社やチームによって全然違うと思うのだが、この4定義は結構分かりやすい気がするので、初心者の方はとりあえずこれをベースに覚えておいてもらえばいいのかもしれない。

Section I ではテスト技法1つにつき1章という感じの構成になっている。せっかくなのでそれぞれについて感想を書きます。

同値クラステスト(同値分割)、境界値テスト、デシジョンテーブルあたりはソフトウェア開発者なら漏れなく知っておいてほしい技法という感じなので特にコメントなし。知らない人はこの本読みましょう。

次にペア構成テストというのがあって、「すべてのペアをテストする」ということらしい。こいつは簡単そうに見えて結構大変では…?と思って読み進めていたら、直行表を作ってすべてのペアを網羅するサブセットを探す的な手法が出てきてこれがまあまあややこしかった。でも変数が多くてテストケースの作成が大変な時は一度やってみていいかもしれないなあ。

状態遷移テスト、ドメイン分析テストはそういう名前があるとは知らずにやっている人が多そうな感じ。気合い入れてテスト書く時はこういうことやるよなー、的な。でも名前があるとテストケースを考えるときに思いつきやすくて便利そう。

ユースケーステストはいわゆるE2Eテストとしてやってる人は多そう。フォーマットという意味では途中で出てくるテンプレートが参考になりそうだと思った。今度使ってみようかな。

ここまででSection I 終わり。Section II ではホワイトボックステストということで制御フローテストとデータフローテストの二種類の技法が紹介されている。

制御フローテストの方にはテストカバレッジの定義の話があるので初学者には是非読んでもらいたい。データフローテストの方は正直ちょっとピンと来ないかなあ。うーん。こういうのはコンパイラにチェックしてもらいたい気持ち。

Section III はスクリプトテストと探索的テスト。そういう名前だったのかお前ら!という感じ。とにかくなるべく早い段階でテストケースをしっかり作ってその通りにやるのがスクリプトテスト、逆にテストを実行しながらやるべきことを考えていくのが探索テスト。この二つを組み合わせてやりましょうねーみたいな話。なるほどねえ。

第14章「テストの計画」には普通に良いことが書いてあったので、一部を下記に引用します。

「計画は、手段と目的をたえず調整し続けるという点で、連続的なプロセスである。また、計画は連続的な調整および改善であるという点で、進化的なプロセスとみなすべきである。

なんかもう、テストに限った話じゃないですよね。素晴らしいです。思わず敬語になっちゃうレベル。

Section IV は補足的な感じだけど、15章にある色々な分類はちょっと興味深い。どこまで意味があるかはちょっとわからないけど、ISO 9126とか一回読んでみようかな…と思ったら有料かあ。うーむ。

最後にSection Vがちょろっとだけある。ちょっと短すぎて引用したら中身全部載せるのと同義になってしまいそうなのであえて引用しないでおきますが、真理が書いてました。普遍の真理。要は、本読むだけじゃなくてちゃんと実践しろってことですね。

そんなこんなでダラダラ感想を書いたわけですが、文章も読みやすいしなかなか良い本だと思う。ソフトウェア開発初学者にオススメできる良書だし、僕みたいにテスト系の本あんまり読んでないなーという人の入りとしてはとても良いと思いました。

2021年振り返り的な何か

いやね、分かってますよ。もう一月も終わろうとしているわけで。こういうのって普通2021年末にやるか、遅くとも年始くらいにやるでしょ。1/31て。まあ自分の中で「一月中ならギリセーフ」みたいな謎の一線があるのでそこのギリギリのラインを攻めて行きたいと思います。(?)

というわけで昨年の年始…もとい、二月に設定したOKRを振り返ってみようと思う。しかしOKRを真面目にやったことがないので振り返る方法もよく分からない。ちゃんと調べるのも面倒なので雰囲気でやってみよう…とりあえず各Key Resultを見ていった上で、当初の目標になかった成果等も加味して最終的な評価(0~1?)つける。これで。

二月の記事で設定したObjectiveは「初心に返って学び直しをする」だった。各Key Resultについて一つずつ見ていく。

Key Results

技術書を25冊読む

ブログ記事の「技術書」カテゴリを見ると、9冊しかない。あれれ~おかしいぞ~?(名探偵)

実際にはSoftware DesignとかWEB+DB PRESS読んだり、他にもサーバレスアーキテクチャの本とかJavaRuby関連書籍、マネジメント系の本etcをいくつか読んではいるのだが、如何せん最後まで読み切らないケースが多くて記事を書く気にならないのであった。(最後までちゃんと通読して、理解したことをまとめないと記事を書く気にならない…)

実際には25冊近く読んでいる気はするのだけれども、最近記憶力があからさまに落ちてきていて、しっかり記事にするくらいしないとなかなか記憶に定着しないので、ちゃんと25記事書く形にしたかった。達成率低すぎィ!

今年は25記事をガチで目指そう…

ソフトウェア開発以外の本を10冊読む

記事としては8記事となってまたまた未達成。これもまた実際には図書館で借りてきた仏像・観光・建築・アート・お金あたりの本をまあまあ読んでいて、こちらは完読したものも多い。でも途中から面倒になってきて記事にしていないのであった。

「直島誕生」とかはすごく面白かったので読書感想文を書きたかったのだけれども、どうも仕事が忙しくてそもそもブログを書く気力がなかった…。今からでも書きたいけどだいぶ忘れてしまったなあ。

新しいコミュニティに2つ以上参加して継続する

目標を立てた時点でイメージしていたのは、(自分にとって)新しい技術コミュニティに参加していくことと、オンラインサロンというものに一度入ってみようかなという感じであった。エンジニアと人生コミュニティとか。(元々はサロンという名前だった気がする)

が、実際はだいぶ方向性が変わっていて、まずこの情勢であまり勉強会やカンファレンスなどに参加する気になれなかった。そもそも育児になるべくリソースを割きたいので業務時間外の時間の使い方がかなりシビアであり、JJUGセミナー何回か聞いたりrust-jp Slackに入った程度で終わってしまった。

また、縁あってフィヨルドブートキャンプというプログラミングスクールにメンターとして参画することになった。正直プログラミングスクール業界については完全に訝しんでいたのだが、フィヨルドブートキャンプ通称FBCは自分の知っているスクールとはだいぶ違った。そもそもいい評判を聞いていたし、知り合いが中にいたので色々話を聞いて、是非お手伝いしたいということでメンターの末席を汚させてもらっている。メンター陣が豪華すぎて自分なんかが居てもいいものかと思ったりもするが、まあ自分なりに頑張ってプログラミングを学びたい人をサポートしている。

で、なぜこの項目でFBCについて触れたのかというところ。FBCはスクールという感じがあまりしなくて、むしろ「コミュニティ」感が強い。受講生とメンターという立場の違いはあれど、個人的にはプログラマとして一緒に頑張る仲間のように(勝手に)感じている。例え未経験であれ、プログラミングを頑張っている時点でもうプログラマなのだ。もちろんメンターとしての責務はしっかり果たすよう努力しているが、それにしてもDiscordで技術に関係あることやないことをワイワイ話しているこの感じは「コミュニティ」以外の何物でもないと思う。

そんなわけで、今の自分にとってFBCは副業先でもあり大切なコミュニティでもある。「2つ以上参加」は達成できなかったが、継続して参加できるコミュニティが一つ見つかっただけでも個人的には十分な成果だった。引き続きメンター業頑張ります。あ、プログラミングを学びたい方はフィヨルドブートキャンプがおすすめですよ〜是非見てみてください!(唐突な宣伝)

bootcamp.fjord.jp

仕事で使用している技術スタック全てを基礎から勉強し、同じスタックで個人プロダクトを出す

はい。やってません。ごめんなさい。

誰に謝っとるんだという感じではあるが、弁明します(誰に?)。代わりといってはなんですが、仕事で一から小さなアプリケーションを一人で作りました。半ば無理やり自分でやった。やりたかったから。今では反省している。

まあこれが結構いい経験だったので、頑張ってやってよかったと思う。一から作るところの経験をするのが目的だったので実質達成と言っていいのでは…!?いやダメか。今年はやろう…(毎年言ってる)

あと、「公式ドキュメント全部読む」をやらないといけない。これを強く感じた。Springのドキュメント、多いなあ…。 公式ドキュメント全部読むに関して、何度も読み返したいQuora回答はこちら。この文章は本当に素晴らしすぎる。

qr.ae

英語の勉強をして何かしらの試験を受けてスコアアップ(TOEIC換算で比較)

ELSAをやったり、Rust the bookPoEAAを英語で読んだり(両方未完)したものの、どうにも中途半端になってしまった感が拭えない。

最近はJolly Phonicsというのを子供と一緒にやっていて、発音を少しでもマシにしたいなー等と思っている。しかし子供はこれを勉強などとは露ほども思わずただただ楽しい遊びだと思ってやっているので、上達がめちゃめちゃ早い。耳がいいとかカタカナ英語を知らないというのもあるだろう。とにかくやたら発音が良くてどう考えてもお父さんは完全なるジャパニーズイングリッシュ。娘に「違うよーこうやっていうんだよ。お口の形をよく見て」とか言われて日々教えられてます。お父さん頑張ります。。

試験で言うとスピーキングの試験を受けた。正直微妙だった。TOEIC換算を直接的にすることはできないが、Cambridgeのレベルで言えば、全然上達はしてなかった。現状維持くらい。うーむ、英語ムズカシイ。継続的にやるしかないな。

ブログをなんでもいいから100記事書く

50記事だった。ちょうど半分。特に後半の失速具合がすごい。毎日書いてる人とか化け物では?

娘が遊ぶためのWebアプリの新作を出す

イデアに実装力と気力が追いついてなくてできなかった。ただただ無力。もうちょっとしたらPCとか触れそうだしタイピングアプリとか作るのがいいかもなーとぼんやり考えてはいるが、何年か先かな…

プロダクト概要だけ書いて全く開発の進んでいない個人開発モノを全てインターネット上に公開するところまでやる

逆にプロダクト概要だけのものが増えた。

Twitterは一日一時間(?)

平均したら達成している可能性はあるけどそもそも測定するの忘れてた。スマホ変えたし。

技術系の資格を何か取ってみる

AWSのなんかソリューションなんとかアーキテクトみたいなやつを受けよう受けようと思ってたら一年終わってた。

その他

技術以外のところで新しいことをたくさん学んだ気がする。仏像から始まって建築、アート、観光、お金、日本史、アパレル、不動産あたり。学校の成績とかは良かったし十代の頃は自分のことを博識だと思っていた(恥ずかしい!)のだが、今や知らないことが多すぎて逆に楽しくなってきた。全く素人な分野はちょっとかじっただけでどんどん知識が増えて良い。読書が一番優良なコンテンツだと思うけど、最近はYouTubeにも色々あって良い。ただ質の良し悪しを見分けづらいのが難点。あと大河ドラマは良い。

浅く広く知りたいタイプなので、様々な方面に手を伸ばしていきたい。

総評

総じてKRがズタズタ。なーんにも達成してない。でも気持ち的には「去年結構色々やったし学び多かったんでは?良くない?」てな感じなので、まあいっか。数字つけるとしたら0.2 ~ 0.3くらいな気がするけど。低。

「初心に返って学び直しをする」はどのくらいできたのか定性的に考えてみると、技術面ではどうかちょっと分からないけどそれ以外の領域では初心に帰るというより初心者丸出しで色々勉強できたので結果的には割とできたんではないかな。うんうん。自分を褒めるスタイルでいこう。

OKRのおかげでチャレンジすることの方向性をある程度ぶらさずにいられたような気がしなくもないので、今年もやったほうがいいかな。でも達成できてなさすぎて微妙に凹んでもいるので、悩むなあ。うーむ。

あ、書いてるうちに二月になってしまった…(また一つ目標達成できなかった感)

まあ人生全体的にこんな感じな気がするな。のらりくらりとやっていこう。