ScalaMasturi 2024で, 拙作の拡張可能レコードのライブラリrecord4sについて発表してきました. 発表で触れられなかった点も補足しながら, 内容を文章にしておこうと思います. とくにrecord4s以外のレコード実装との比較についてはこの記事での完全書き下ろしです. モチベーション Scala 3の標準機能による解決 理想 record4s Tips メソッドの定義 例を使ってJSONをデコード 内部実装 フィールドアクセス レコードの結合 重複キー問題 Scalaの他のレコード実装 shapelessのRecord scala-records Karlsson & Haller '18 record4sのArrayRecord Named Tuples 他の言語での例 PureScript TypeScript Haskell パフォーマンス レコード作成の実行時間

転職のお知らせ、あるいは個人の日記です。 6月から以下のように所属変更となっています。 From 株式会社はてな To 株式会社一休 マネージャではなく、とくに役職のないソフトウェアエンジニアとして働きます。いわゆるIC (individual contributor)というやつです。 きっかけ はてなには新卒として入社して以来11年も勤めて、インターンやアルバイトとして関わった時期から数えると16年になります。出入りの激しいこの業界でずっと1社しか知らずに過ごすのは負い目に感じていました。また、年齢的にも今年で40歳になることもあって、そろそろ転職を経験しておかないとまずいという焦りもありました。 そんなときに、大学の同期でプライベートでも仲良くさせてもらっているid:suzakから声をかけてもらい、ちょっと真剣に転職を考えたのがきっかけでした。 できることではなくやりたいこと はてなで

この記事はScala Advent Calendar 2023の13日目です. Scalaのライブラリを作るとき, 複数のScalaバージョンに対応させてクロスプラットフォーム(JVM, Scala.js, Scala Native)に対応させて, CIも設定して...とやるのは割と面倒です. 実はsbt-typelevelというsbtプラグインを使うと, この辺の面倒な設定をほとんどいい感じにやってくれます. この記事では, sbt-typelevelの基本的な導入方法と, 細かい設定ノウハウを紹介します. sbt-typelevelとは 基本設定 プラグイン設定 build.sbt設定 コンパイラ設定 クロスプラットフォーム設定 CI設定 クロスバージョン ターゲットブランチ カバレッジ計測設定 リリース設定 アカウントの準備 古いアカウントを持っている人 リリースサイクルの指定 アー

この記事はScala Advent Calendar 2023の12日目だ! Scala 3のマクロを書く上で役に立つ, メタれたTipsたちを紹介するぜ! 勢いに任せて書いていくからサンプルコードがちゃんと動かなかったらごめんな. 一応, Scala 3.3.1を想定しているぞ. マクロ 1. メソッドをマクロとして定義する 2. マクロの本体を実装する 3. マクロ実装の記法の意味を知る 4. マクロで生成されるコードの内容を確認する 5. 引数の式を評価せずに使う 6. 返り値の型をマクロの実行結果によって決める 7. マクロの返り値の型を制限する 8. マクロの返り値の型を書かない 9. マクロで計算された型をテストする 10. マクロで計算された型をScalaTestでテストする 式 11. 定数式の値を得る 12. 定数式でなければコンパイルエラーにする 13. 定数値の式を作

この記事はScala Advent Calendar 2023の11日目です. 最近, 趣味でScala 3のコードをだいぶ書いていて, マクロの使い心地のよさに感心しました. 理論的な背景も含めて, 産業界で多く使われているプログラミング言語の中では筆者の知る限りぶっちぎりに優れたマクロを備えています. 他の言語にも見習ってほしいですね. たぶん見習おうとすると処理系を作り直す羽目になりますが. この記事ではScala 3のマクロのすごいところを例を使って紹介します. マクロの実践的な例 準備 実践的な例: NamedArray – 名前でアクセスできる配列 NamedArrayのマクロ実装 記述が明瞭 メタレベルのプログラムの扱い クォートとスプライスがある パターンマッチもある 生成コードに型がつく 多段階計算に基づいている クォートとスプライスの本当の意味 ネストしたスプライス ネ

この記事はScala Advent Calendar 2022の19日目です. Scalaではジェネリック型の変性(variance)は+や-で指定しますが, 他の言語(たとえば, C#, Kotlin)ではoutやinだったりします. この記事では変性の意味を整理して, なぜScalaでは+/-の記号を使うのか説明します. 追記ただし, ここで説明している内容は基本的にC#やKotlinでも成立する(はずな)ので「なぜこれらの言語では+/-の記号を使わないのか」を説明するものではありません. 個人的には+/-の方がわかりやすいと思うし, out/inの記法は扱っている概念が簡単であるかのような誤解を生む(悪く言えば騙す)のでどちらかと言うと嫌いです. 発端 こういう話題がありました. Scala は共変が + で、反変が - なので理論重視？ なのに対して、Kotlin と TypeSc

この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,

若手メンバーのスキルアップのための相談に乗っていると, うまい設計ができるようになる, 仕様の整理やメリット・デメリットの判断がうまくなる, あるいは技術の引き出しを増やすにはどうしたらよいか, という話がよく挙がる. この手の話題にいつも同じようなアドバイスをしていると気づいたので, 説明を楽にするために書き下しておく. ソフトウェア開発の話だけど, もしかしたら一般的な仕事のやり方の話だと思っても成立するかもしれない. 文脈 ソフトウェア開発のプロジェクトを進めるとき, 少人数の精鋭だけで開発するなら極論するとカウボーイコーディングでも成立するかもしれない. そうでなければ, たとえばスクラムのように, なんらか段取りをチームでマネジメントし, 不確実性を下げるためにどういう方法でアプローチするか検討し, 仕様を固めて細かいタスクに分解するプロセス(以降ざっくり「ソリューションを定める

結論から言うと, 名前を付けることなく再帰的な関数を定義することは可能. 特定のプログラミング言語でどうかというよりは抽象概念としての関数の再帰を名前なしに実現可能かどうかという話(名前なしに実現できるプログラミング言語は存在するかという話). 発端 id:naoyaさんがこういうツイートをしていた. 再帰を書くときに何気なく関数に名前つけたり let で束縛したりしてたけど「再帰には三項関係が必要でありその実現には記号が本質的に関わる」とあり、名前づけの行為が必然だったことが分かった。プログラミングするときの視点が変わるな— naoya (@naoya_ito) 2022年8月12日 たとえば以下のように書いたときのlet fact =みたいな話. let fact = n => n <= 1 ? 1 : n * fact(n-1) ちなみに, 話は一見逸れるけど, こう書けると必然的に

このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを

こういう話です: 現代においてprintデバッグなんて恥ずかしいもの。デバッガーを使いこなさないといけない。って認識してたけど、以外とprintデバックの方がサクッと気軽にできて良いとやってる人が多くて安心した。（vim-jpより— てらまこ (@teramako) 2022年3月28日 以下の記事に以前書いたことがあったけど、別な話題を1つの記事に混ぜていると後から参照しづらいため、独立した記事に起こしただけで、とくに新しい話はありません。 この記事はEmacsのdap-mode (debug adapter protocolのためのプラグイン)をScalaで有効にする方法を書いたもので、しかしそれは本当に要るのか? という疑問があります。 デバッガは本当に使うのか テストの単体実行は(debugではなくrunの方で)毎日使ってるけど、dap-modeのデバッガは正直まだ一度も役立ったこ

またか. またなのか. 何回目だ. ということで, ラムダ計算のインタプリタの実装としては4回目くらい*1, コンパイル時計算でやるものとしても3回目くらいになってしまうけど, ラムダ計算の処理系をまた書いてしまった. 今回の目的は, Scala 3にはmatch typesという機能があり, これだけでチューリング完全なのではないか, というのを検証するため. また, 文字列リテラル型を操作する型レベル関数が3.1.2-RC1にきていて, これを使えば構文解析器だって書ける. 経緯 過去の事例 関数と返り値 パターンマッチと再帰呼出し Scala 3の型レベル言語 match types リテラル型操作 ラムダ計算の実装 評価 印字 構文解析 型推論 (型検査) おわりに 経緯 もともとは, id:xuweiさんが文字列リテラル型でコンパイル時に動作する構文解析器を実装していたのが始まり

数日前にTwitterで, JavaScriptのオブジェクトに対する===の挙動が初心者には難しいみたいな話を見かけた. 発端や周辺の議論をちゃんと追いかけてないからとくに出典は貼らない. たぶん元々の話は「へぇ, こういう挙動なんだ, 簡単ではないね」くらいの話だったのかもしれない. 自分のタイムラインの観測範囲では「そうだそうだ, (参照の同一性ではなく)同値性にしとけばいいのに」と思っている人もそれなりにいそうに見えた. 個人的にも同値性が簡単に確認できるとよい気はするものの, 「なんでそうしないんだ, オブジェクトの中身を確認していくだけだろ!」みたいな簡単な話ではないことも知っているため, 以下のようなツイートをしたのだった. JavaScriptのオブジェクトの同値性、再帰的な構造とか作るとぜんぜん自明じゃないんだよなぁ。リンクの構造は違うけどプロパティを辿ったときのパスはど

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

社内でOSSへの貢献をもっと奨励していきたいねと話していて, そもそも普段どれくらい貢献できているか知りたくなった. 以前, 自分のポートフォリオに貢献しているOSSのリストを出すのをやっていて, ちょっと改造したら組織内のメンバー全員のものもすぐに出せそうだったのでやってみた. (というのをずっと前にやっていたけど宣伝するのを忘れていた.) モチベーション OSSに(趣味にせよ仕事の一部にせよ)貢献している同僚はけっこういるけど, 「こういうのやったよ!」と宣伝してくれない限りあんまりどういう活動をしているのか知らない. 「今月はこれだけの人たちがOSS貢献してました」というのを社内の全エンジニアで眺めてわいわい盛り上がれると, 自分も何かやってみようという気になるだろうし, 「これに手をつけてみたいけど, どこから手をつけたらいいかわからないから詳しそうなあの人に聞いてみよう」となって

この記事は, はてなエンジニア Advent Calendar 2020の20日目です. 昨日はid:Pasta-Kによるウェブブラウザにバグ報告をするときにやることでした. 明日の担当はid:motemenです. Scalaで, 依存ライブラリのバージョンを上げるpull requestを自動的に作ってもらうソリューションとしてはscala-stewardがあります. ScalaのことはScalaでやるのが確実そうなので安心感がありますね. ただ, scala-stewardを自分でホストするのは面倒だし, かと言ってGitHub Actionsで動くようにするのもそれなりに面倒なようです. Scalaに特化しない方法としてはRenovateがあります. これはいろんな言語のライブラリ等のバージョンをぜんぶ面倒見てくれてべんりです. GitHub Appsになっているのでポチポチ設定する

こういう話がありました。 Feature Request : Support for scala in dap-mode · Issue #196 · emacs-lsp/dap-mode を見てもdap-modeの使い方がよく分からなかったし別に時間をかける所じゃないなと思ったので、デバッグする時だけはIntelliJを使うことにしようとしたのですが、私の環境だとUIが崩壊してデバッグ設定以前の問題になってしまいます。 実はMetalsの(というかlsp-mode+dap-modeの)デバッガはいま普通に機能するけど、確かに使い方(使える状態にするコツ)がちょっとむずかしい感じがしますね。実際にはやることはあんまりないんだけど、いざやろうとすると時間を食うと思うので、時間を食われてやった側の人間としてやり方を書き記しておこうと思います。本当は最近のEmacsのモダンな環境ぜんぶ紹介するみ

こういうのがあった: 二時間目コンテナの講義ではDocker Quizが出題。君は、すべて解くことができるか？ $ docker run --rm -i hatena/intern-2020-docker-quiz #hatenaintern2020— hatenatech (@hatenatech) 2020年9月7日 自社のインターンの課題だけど, 僕は今年のインターンには全く関わっていないので, 新鮮な気持ちで問題を楽しめた. みんな話題にしているのはQ7でなかなか骨がある. 全体的にCTFっぽさがある(参加したことないのでしらんけど)中で, Q7はとくにそっち方向の面白さがある. Q7 このイメージのentrypointとして指定されているコマンドのソースコードを復元して、この問題の答えを取得せよ 「ソースコードを復元して」と言われて「うーん, それホントに復元しないとダメかな?」

How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ

自分の過去の登壇・執筆情報の管理が面倒になってきたのと, Twitter等に貼ってあった自己紹介のページがあまりに得体が知れない感じになってしまっていたので, ポートフォリオというかプロフィールというか, そういうものを用意することにした. 静的ページでいいけど, 1次情報はYAMLかなにか, 管理しやすいものになっていると助かるので, まぁJekyllでいいでしょ, という感じでミニマルに作りはじめた. ブログ記事とかGitHubのリポジトリとかもかいつまんで載ってるといいかもね, とやっていったらそこそこのボリュームになってしまった. でも最近は歳を取ったのか趣味でコードを書くモチベーションが低くて全体的に意識が低い. できたもの ソースコード https://github.com/tarao/tarao.github.io/ Jekyll まず一番の目的としては, 文献リストを表示し