部分型における変性と極性 - なぜScalaの変性は+や-で指定するのか

この記事はScala Advent Calendar 2022の19日目です.

Scalaではジェネリック型の変性(variance)は+や-で指定しますが, 他の言語(たとえば, C#, Kotlin)ではoutやinだったりします. この記事では変性の意味を整理して, なぜScalaでは+/-の記号を使うのか説明します.

追記

ただし, ここで説明している内容は基本的にC#やKotlinでも成立する(はずな)ので「なぜこれらの言語では+/-の記号を使わないのか」を説明するものではありません. 個人的には+/-の方がわかりやすいと思うし, out/inの記法は扱っている概念が簡単であるかのような誤解を生む(悪く言えば騙す)のでどちらかと言うと嫌いです.

テックリードを再生産可能にする - テックリード養成講座をやっている話

この記事はEngineering Management Advent Calendar 2022の7日目です.

今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね).

テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います.

*1:エンジニアリングマネジメント4領域のうちすべてではないがいくつかを担っているEM

方法不確実性を下げるための松竹梅メソッド

若手メンバーのスキルアップのための相談に乗っていると, うまい設計ができるようになる, 仕様の整理やメリット・デメリットの判断がうまくなる, あるいは技術の引き出しを増やすにはどうしたらよいか, という話がよく挙がる. この手の話題にいつも同じようなアドバイスをしていると気づいたので, 説明を楽にするために書き下しておく. ソフトウェア開発の話だけど, もしかしたら一般的な仕事のやり方の話だと思っても成立するかもしれない.

関数の再帰的な定義に名前付けは必要か

結論から言うと, 名前を付けることなく再帰的な関数を定義することは可能. 特定のプログラミング言語でどうかというよりは抽象概念としての関数の再帰を名前なしに実現可能かどうかという話(名前なしに実現できるプログラミング言語は存在するかという話).

発端

id:naoyaさんがこういうツイートをしていた.

再帰を書くときに何気なく関数に名前つけたり let で束縛したりしてたけど「再帰には三項関係が必要でありその実現には記号が本質的に関わる」とあり、名前づけの行為が必然だったことが分かった。プログラミングするときの視点が変わるな

— naoya (@naoya_ito) 2022年8月12日

スクラムでベロシティを安定化するにはどうしたらよいか

このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている.

スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった.

一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる.

この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを安定化させたらいいんだよ」という部分に悩んでる人が多いように見える. 僕はこれに関してはある程度の精度で答えを持っていて言語化できそうだなと思ったので, 連投ツイートしてみた. この記事は一連のツイートをもう少し丁寧に説明したバージョン.

デバッガを使うのは効率がよいのか

こういう話です:

現代においてprintデバッグなんて恥ずかしいもの。デバッガーを使いこなさないといけない。って認識してたけど、以外とprintデバックの方がサクッと気軽にできて良いとやってる人が多くて安心した。（vim-jpより

— てらまこ (@teramako) 2022年3月28日

以下の記事に以前書いたことがあったけど、別な話題を1つの記事に混ぜていると後から参照しづらいため、独立した記事に起こしただけで、とくに新しい話はありません。

この記事はEmacsのdap-mode (debug adapter protocolのためのプラグイン)をScalaで有効にする方法を書いたもので、しかしそれは本当に要るのか? という疑問があります。

Scala 3のマクロの練習に拡張可能レコードを実装してみる

Scala 3でコンパイル時計算がいろいろ便利になっていそうなので, 練習として拡張可能レコード(extensible record)を実装してみた. 前回はmatch typesで型レベルの操作のみでいろいろできたから, 今回もそういうつもりでやろうと思ったものの, けっきょくマクロが必要で, Scala 3のマクロの練習という感じになった. Scala 3のマクロはScala 2からはだいぶ変わっていて, かなり便利になっていることがわかった.

コンパイル時計算でラムダ計算の構文解析器・評価器・型推論器を実現 (Scala 3編)

またか. またなのか. 何回目だ. ということで, ラムダ計算のインタプリタの実装としては4回目くらい*1, コンパイル時計算でやるものとしても3回目くらいになってしまうけど, ラムダ計算の処理系をまた書いてしまった.

今回の目的は, Scala 3にはmatch typesという機能があり, これだけでチューリング完全なのではないか, というのを検証するため. また, 文字列リテラル型を操作する型レベル関数が3.1.2-RC1にきていて, これを使えば構文解析器だって書ける.

*1:OCamlのサブセットとかJavaのサブセットとか他の言語も含めるともっと多い

再帰的な構造のデータの同値性判定はどうしたらいいか

数日前にTwitterで, JavaScriptのオブジェクトに対する===の挙動が初心者には難しいみたいな話を見かけた. 発端や周辺の議論をちゃんと追いかけてないからとくに出典は貼らない. たぶん元々の話は「へぇ, こういう挙動なんだ, 簡単ではないね」くらいの話だったのかもしれない. 自分のタイムラインの観測範囲では「そうだそうだ, (参照の同一性ではなく)同値性にしとけばいいのに」と思っている人もそれなりにいそうに見えた.

個人的にも同値性が簡単に確認できるとよい気はするものの, 「なんでそうしないんだ, オブジェクトの中身を確認していくだけだろ!」みたいな簡単な話ではないことも知っているため, 以下のようなツイートをしたのだった.

JavaScriptのオブジェクトの同値性、再帰的な構造とか作るとぜんぜん自明じゃないんだよなぁ。リンクの構造は違うけどプロパティを辿ったときのパスはどうやっても一致する(観測上は同じに見える)やつを同じとすべき? とか。

— INA Lintaro (@oarat) 2021年8月17日

補足しとくと、x = { a: { a: x } } と x = { a: x } は同じか、みたいなやつ。(同じでいいとおもうがそれをちゃんと判定できるか。)

— INA Lintaro (@oarat) 2021年8月17日

オブジェクトの同値性を判定するメソッドや演算子を実装しようとすると, 再帰的な構造があると困ってしまう*1. なぜなら循環している可能性があるから. 同値性を判定できないと主張したいわけではなくて「同値性をどう定義したらいいか自明ではない」という話.

*1:それ以外にも, 同値性判定に計算コストがだいぶかかってしまう(効率よく計算できるようにするのがたいへん)といった問題もある

テックリードの抱えるプレッシャとキャリアパス

テックリードを過去に3年くらい, まだ「テックリード」という名称が社内で正式に制度化されていない頃も含めると6年くらいやっていて, 今はテックリードを若者に譲っていわゆるエンジニアリングマネージャ(社内での名称はいまのところ「グループチーフエンジニア」)をやっている. 現役テックリードの悩みを経験者として聞くと「そうそう, あるある」と思う一方で, まとめてみるとそれらは実はその先のキャリアパスに綺麗につながっていることに気づいた. 以下, 社内向けに書いたテックリードの抱えるプレッシャのまとめに, キャリアパスの話を加筆したもの.