Scalaライブラリのプロジェクト設定にベストプラクティスを適用してくれるsbt-typelevel

この記事はScala Advent Calendar 2023の13日目です.

Scalaのライブラリを作るとき, 複数のScalaバージョンに対応させてクロスプラットフォーム(JVM, Scala.js, Scala Native)に対応させて, CIも設定して...とやるのは割と面倒です. 実はsbt-typelevelというsbtプラグインを使うと, この辺の面倒な設定をほとんどいい感じにやってくれます.

この記事では, sbt-typelevelの基本的な導入方法と, 細かい設定ノウハウを紹介します.

続きを読む

Scala 3のマクロTips 100連発

この記事はScala Advent Calendar 2023の12日目だ!

Scala 3のマクロを書く上で役に立つ, メタれたTipsたちを紹介するぜ! 勢いに任せて書いていくからサンプルコードがちゃんと動かなかったらごめんな. 一応, Scala 3.3.1を想定しているぞ.

続きを読む

あらゆるプログラミング言語の最先端を行くScala 3のマクロ

この記事はScala Advent Calendar 2023の11日目です.

最近, 趣味でScala 3のコードをだいぶ書いていて, マクロの使い心地のよさに感心しました. 理論的な背景も含めて, 産業界で多く使われているプログラミング言語の中では筆者の知る限りぶっちぎりに優れたマクロを備えています. 他の言語にも見習ってほしいですね. たぶん見習おうとすると処理系を作り直す羽目になりますが.

この記事ではScala 3のマクロのすごいところを例を使って紹介します.

続きを読む

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

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

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

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

続きを読む

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

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

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

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

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

続きを読む

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

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

続きを読む

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

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

発端

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

続きを読む

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

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

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

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

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

続きを読む

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

こういう話です:

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

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

続きを読む

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

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

続きを読む