Cherry Industrial Keys – NovelKeys LLC
キーキャップもなかなか気に入ったものに巡り会えないけど、これは一目見て欲しい！となった。
しかし、余ったキーキャップどうしよう。。
『n月刊ラムダノート Vol.1, No.3(2019)』でパターンマッチについて学ぶ
n月刊ラムダノート Vol.1, No.3(2019)www.lambdanote.com
残念ながらPerlでは早い段階から導入されたもののエッジケースが潰せず非推奨になったパターンマッチ(5.10で導入され、5.18で非推奨に)、最近いろいろな言語に導入されていますね。
普段わりとScalaに触れる機会が多いので、当たり前のように使っていますが、Javaにもバージョン21から導入されました。
そんなパターンマッチは、どのように実現されるのか、どんな検討を経て仕様が決まっていくのか、非常に興味深い記事2本が掲載されている、ということで『n月刊ラムダノート Vol.1, No.3(2019)』買ってみました。
『実践プロパティベーステスト』、ラムダノート社から直接買うときに、『n月刊ラムダノート』を同時に購入すると送料が無料になるということで、一緒に『n月刊ラムダノート Vol.1, No.3』を購入
— magnoliak🍧 (@magnolia_k_) 2023年11月4日
パターンマッチ特集なのが良い
1 代数的データ型とパターンマッチの基礎（κeen）
2 パターンマッチ in Ruby（辻本和樹）
『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』は、言語に関係なくプロパティベーステストを学びたい人はすぐ買うべき
Erlang/ElixirのPropErというライブラリをベースに、プロパティベーステストの考え方、テストの実践的な書き方を学ぶための本です。
『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com
書名だけ見ると「Erlang/Elixirは使ってないからなー」と避けてしまうかもしれませんが、それはもったいなく、言語に関係なく、”プロパティベーステスティング”という手法の本質的な活用の仕方が学べるようになっています。
ここしばらくScalaのScalaCheckというプロパティベーステストライブラリを使ってテストを書くことに挑戦していたのですが、今一つより良い書き方が分からず、何か参考になる情報が無いかと探しているタイミングでこの本が出版されたので、早速買って読んでみました。
プロパティベーステストは、テストコードを「テスト対象のコードが満たすべき特質（プロパティ）」と、「テストデータの生成」を分離し、予め用意された「ジェネレータ」が大量のテストデータを自動かつ、ランダムに生成することで、手動で作ったテストデータだけでは考慮できていなかったルートのバグを炙り出す手法です。
例えば、「二つのリストの長さをそれぞれ計算してから足した結果と、リストを連結した後に計算した長さは一致する」という特質（プロパティ）をScalaCheckで書くと以下のようになります。
scala> val propConcatLists = forAll { (l1: List[Int], l2: List[Int]) => l1.size + l2.size == (l1 ::: l2).size } Check the property! scala> propConcatLists.check + OK, passed 100 tests.
これだけで100個のパターンが自動で生成されてテストされます。
当然、特質を満たさないパターンがあればエラーになります。
scala> val propSqrt = forAll { (n: Int) => scala.math.sqrt(n*n) == n } scala> propSqrt.check ! Falsified after 2 passed tests. > ARG_0: -1 > ARG_0_ORIGINAL: -488187735
負の数を二乗して、平方根(sqrt)を元の数とは一致しないので、エラーになりました。ARG_0や、ARG_0_ORIGINALという二つのパターンが並んでいますが、これは一度発見したエラーパターン(-488187735)を元に、よりシンプルなパターン(-1)を自動的に探してくれるShrinkingという概念によるもので、プロパティベーステストのライブラリでは必ず用意されている機能の一つです。賢いですね（そんなに上手くいかないことも多いですが）。
このように、話を聞くと「これは凄い！」と思って早速書き始めたくなるプロパティベーステストですが、実際に描き始めるとサンプルコードに出てくるようなシンプルは事例はよくても、実際のコードに対する適切なデータの生成を考えていくと、とても苦労して、いくつもの壁にぶつかります。
本書は、このような「プロパティベーステストを書こうとするとぶつかる疑問点」を上手く解消するように、Erlang/ElixirのPropErというライブラリをベースに、プロパティベーステストの考え方、テストの実践的な書き方が学べるように構成されています。
「どうやってテストしたい内容を汎化するか」「どうやって不変条件を積み重ねて、コードの特質の確らしさを積み重ねていくか」「用意されたジェネレータを元に、自分が欲しいデータを組み立てていくか」「そもそもテストってどうやって組み立てていくのか」「実際のビジネスロジックに応じたテストはどうやって書くのか」
プロパティベーステストを書き始めてぶつかり疑問に対する答えがみんな書いてあります。凄い！
プロパティベーステストでは、具体的なパターンを一度「汎化させる」という抽象化のステップが間に入るので、これまでの「自分で思いついたテストパターンを挙げていく」だけでおわらず、「そもそもこのテストパターンを汎化させると、どんな構造になるのか？」を考える必要が出てきて、改めてテストしようとするコードについて考えることとなり、コードに対するより深い理解が得られることになります。
そのための時間（テストを考える時間だけでなく、大量に生成されたテストを都度実行する時間も必要です）と、膨大なテストの自動生成による品質確保（品質の安定化ともいえます）というトレードオフをどのように判断するかによってプロパティベーステストを導入する否かが決まってきますが、まずは一度じっくりその考え方を学んでみないと、そのトレードオフも判断できないので、ぜひ本書で学んでみることをお勧めします。
なにより、この時代に「Erlang/Elixirのプロパティベーステストの本を和訳して商業出版しよう！」という心意気がいいですよね、こんな本は買っていかないといけないのです！
ペーパーバック版の『Functional Programming in Scala, Second Edition』を買った
既にセールの時に電子書籍版で買っていた『Functional Programming in Scala, Second Edition』、ペーパーバック版の方も追加で買った。
ソフトウェア関係の技術書がこの先、どのくらい需要があるのか、タイムリーに改版されるのか、更には日本で翻訳版が出版されるのか......市場のことはよく分からないけど、「この本はずっと手元に置いておく価値が有る」と思ったものはなるべく紙の書籍で手元に置くようにしている。
電子書籍だと、すっかりその存在を忘れてしまって、最後まで読まなくなってしまうのと、情報の価値はその物理的な存在感ではなく、あくまでコンテンツそのものである……とは分かっていても、一定の金額を超えてくるとどうしても物理的な存在感が無いとなーと思う側面もある。
海外の出版物の印刷物としてのクオリティは、「まぁ、電子書籍でもいいかな」と思わせるレベルのものも多くて、日本の書籍ほどの「モノとしての魅力」を感じないところもあるけど、じゃあ一方でソフトウェアの技術書に「印刷物としての、モノとしての魅力」を見出すべきか？という話も有って。
とりあえず知っている人が書いている本はなるべく紙の書籍で買うようにはしていて、「印刷物としての、モノとしての魅力」は簡単には失われないで欲しいとも思っている。
Scalaわいわい勉強会へ参加した
最近、圧倒的なScala情報の発信でおなじみの 
id:Windymelt さんによる主催の「Scalaわいわい勉強会」に参加した。
場所は、「はてな東京オフィス」……1年に1回くらいビルの前を通ることは有っても、コロナ禍が始まってから中に入ることの無かった場所に久しぶりに入ることができた。
久しぶりの、はてな東京オフィスに来た https://t.co/KLKKrO9TCy
— magnoliak🍧 (@magnolia_k_) 2023年10月13日
ちょっと遅れて会場に到着、その時点ですでに 
id:tanishiking24 さんの「Scala Days Madrid レポート」が始まっていた。発表の後も含めて海外のScalaの動向が聞けたのと、ScalaDaysの様子のオシャレ映像が良かった。
続いて id:Windymelt さんの「https4s」の入門。ScalaでHTTPサーバを書くためのフレームワークでの解説。
その後はLT4連発
その場限りの発表も有って、「あーオフラインイベントだなー」感が良かった。
会場での懇親会を経て、二次会へ。
先日のWEB+DB Pressの22.9周年パーティの2次会(3次会？)で初めてお会いした、きしださん（
id:nowokay）がいらっしゃったので、きしださんから見たScala、という話が聞けたのが良かった。まさか２ヶ月連続でお会いできるとは。
運営陣の圧倒的なホスピタリティの高さが心地よく、大変に良いイベントでした。
2回目が開催された時は、ぜひ発表したいですね
Kailh Clione Limacina Tactileを導入
周りに人が居るような環境、つまりキーの音を気にするような場所でのベストスイッチは”Kailh Midnight Silent V2 Switch Tactile”なのだけど、やっぱり静音スイッチは、打鍵感がもにょっとしてて、すべてが最高！とまではいかない...
というわけで、別に透明のキーキャップを使っている訳でもないけど、"Kailh Clione Limacina Tactile"を自宅のキーボード用に導入……うん、これ最高だ！
Kailh Clione Limacina スイッチkeychron.jp
ストロークの深さとか、打鍵した感じとか、これまでのキースイッチの中で一番気に入った。
まったく透明感は関係無いけどね。
音を気にするような場所で使うなら、”Kailh Midnight Silent V2 Switch Tactile”は引き続き最高におすすめです。
スケジュールを変えるためのオーバーヘッド
開発の管理を強化すればするほど、タスクの変更や、スケジュールの入れ替えを「ご説明する」オーバーヘッドの方が大きくなり、実態に合わせた方向転換ができなくなり、問題はさらに拡大していく
— magnoliak🍧 (@magnolia_k_) 2023年10月5日
この方向転換にかかわるオーバーヘッドが可視化されないと、真の問題に行きつかなくなる
アジャイルか、ウォーターフォールかという対立軸じゃないんですよ
— magnoliak🍧 (@magnolia_k_) 2023年10月5日
方向転換に伴うオーバーヘッドをどこまで事前に見込んで計画するか、「この世の全ては上手くいくはずだ」という、前提で進めるか、なんですよ
後者の場合、あらゆる階層でオーバーヘッドを見越したバッファを入れ始めてしまうんだ
オーバーヘッドを最初から可視化していればいいんだけど、色々なプロジェクト管理のテクニックが「戦術としてのバッファをどう取るか？」という話に行きがちなんだけど、それはそれで正しいのか？って話だよね
— magnoliak🍧 (@magnolia_k_) 2023年10月5日
一見して計画通りに行っているとしたら「外には計画通りにいくように見せるための変更バッファが十分に積まれている」状態であることは想像に難く無い。
じゃあ、どのレイヤーまでそのバッファを見せるか、バッファを積まずに変更を見せていくか、バッファは有るけど変更は見せていくか、さまざまなレイヤーでさまざまな積み重ねが行われた結果、こうなるわけです。
バッファをあらゆる階層で見込んだ結果として、OS上でディレクトリ掘るにも10営業日みたいなのは珍しくないからね https://t.co/vqSYFEvkvQ
— カルロスわらふじ (@RyoMa_0923) 2023年10月5日
