B-Teck!

お仕事からゲームまで幅広く

【Scala】「Go言語でつくるインタプリタ」をScalaで実装した

なんでこの本をScalaでやったのか

7月に転職してからScalaを業務で書き始めたんですが、なかなか手に馴染んだ感がなく、いくつかの本を写経したりしていました。
昨年末あたりからはコップ本を毎日数ページずつ写経しながら読む、ということをやってたんですが、毎日やってると流石に飽きる。
ということで、ちょっと変わったお題として別言語で書かれた本をScalaで実装しながら読むということをやろうと思ったのがきっかけです。
この本は、以前少しGoを触ったときなどに数回挑んでいたんですが、取り組んだときの忙しさなどなどで序盤で挫折しており、数年越しのリベンジでもありました。

実装

github.com

monkeyという言語について

本書は、monkeyというC言語風の架空の言語のインタプリタを実装するものです。
一部引用すると、

  • C言語風の構文
  • 変数束縛
  • 整数と真偽値
  • 算術式
  • 組み込み関数
  • 第一級の高階関数(関数を引数に受け取る関数)
  • クロージャ
  • 文字列データ型
  • 配列データ型
  • ハッシュデータ型

のような特徴を持つ言語です。

完成したインタプリタは、例えばこんな入力を実行できます。

>>let a = [1,2,3,4];
>>let double = fn(x) { x * 2 };
>>let map = fn(arr, f) { let iter = fn(arr, acc) {if (len(arr) == 0) { acc } else {iter(rest(arr), push(acc, f(first(arr))))}}; iter(arr, []); }
>>map(a, double);
[2, 4, 6, 8]

本の内容

本書は主に字句解析器、構文解析器、評価器の3つの章と、言語にマクロシステムを追加する付録の4つに大別されます。
それぞれがどんな機能か、というのを説明するのは難しいんですが、

  • 字句解析器は入力された文字列を解釈可能な単位に分割する部分
  • 構文解析器は字句解析器で分割されたものをプログラミング言語のルールに則って解析する部分
  • 評価器は解析結果を実行し、変数やREPLに渡すための結果を得る部分

といった感じでした。

これらの実装を進める中で、言語の中で型がどのように表現されるか、組み込み関数はどういう動きをするか、が徐々にわかるような作りになっています。
実装を始めるときにはテストケースが提示されるので、どのような動きを目指せばいいのかもわかりやすかったです。
また、かなり序盤の方でREPLを作成し、REPLで実際に動作させながら読みすすめるので、実際に動いていることによる感動もあり、良い構成だなあと思いました。
全体的にかなり砕けた語り口調だったのもあり、著者(あるいは翻訳者?)と伴走しているかのような気分になったのも楽しかったです。

実装にかかった時間など

実装範囲は本編までの状態で手を動かし初めてからはだいたい24時間くらいの実装時間でした。
日付にすると18日間くらい作業していたみたいです。
実装行数は2000行くらいとかなりコンパクト。

感想

Go前提で書かれている書籍をあえてScalaでやったんですが、Goの記法は割と平易なので、読み替えも簡単で進めやすかったです。
言語間の違いによってScalaへの理解も深められたし、単純な写経ではないので文中の意図を理解する必要があり、却って内容も頭に入ってきた気がします。
本書を通して実装することで、言語の処理系って大体こんなことが起きているんだなあと想像できる余地が生まれました。
付録部分も面白そうなので手をつけようかな〜と思いつつ、とにかくグリーンになれば良しで実装を進めてしまったので、ちょっとリファクタしてからやろうかなという感じです。

ツイート

【振り返り】2022年2月

前月の振り返り
【振り返り】2022年1月 - B-Teck!

学習

今月やったこと

所感

自分の会社では2月が下期スタートということもあり、ひたすらバタバタしていたような気がします。
あっという間に終わっていて、今月は主だったこと何もできていないなあという感じでした。

今月も引き続きすこーしずつコップ本を進めながら、先月読んでた実践Terraformを読了しました。
AWSの知識がうろ覚えのものばかりだったのでちょっと難しかったですけど、わかりやすい本でした。
いい機会なのでAWSもうちょっと理解しようと何冊か積み増したりしています。 コップ本は数ページ読みながら写経して咀嚼するのに1時間とか平気でかかっていて、全然読了が近づいている気がしないです。
数字の上では半分は超えたんですが…。

あとは先月も書いていた、キャリアの話に引続き悩んでいます。
これまでは人の足りないところに飛び込み、必要に応じてスキル習得しながら着地に持っていく、という仕事が多く、中長期のことをあまり考えていませんでした。
ちょっと先を見たときに自分がどうなっているかの姿が全然ないんですよね。
中長期的にはこうなっていたい、と現状の自分に出せる最大出力を出す、は両立できればちゃんと武器になる気はするので、どうにかしたいと思いつつ。
プロダクトとか組織について中長期的にどうあるべき、だからこうするはなんとなく考えられても、自身についてが格別に難しい。
こういう思考の筋肉もつけていかないといけないんだろうなぁという今日このごろです。

趣味の話。 今月はゲームをする元気もあまりなかったので控えめですが、相変わらず基本的にはApexばかりしてました。
あとは何冊か積んでいた小説を崩したり。
なんかここ数年のこの時期はいつもへばっている気がするので、うまくこの流れを断ち切っていきたいところではあります。

来月の振り返りまでには、もうちょっと自分の先の姿について想像できていると良いなぁ。

SaaSの開発ロードマップ、マイルストーンどう決める?【開発PM勉強会vol.8 オンライン】に参加した #開発PM勉強会

peer-quest.connpass.com
に参加してきたのでメモ。
投稿時点で公開されていた資料は記載しましたが、順次追記予定です。

個別最適のSaaSと上手く向き合うプロダクトロードマップ

speakerdeck.com

  • プロダクトロードマップとは
    • 「やることリスト」ではなく「ありたい姿」への最短ルート
    • 2軸で伝える「ありたい姿」
      • 将来プロダクトが実現していたいユーザーの姿を描いた「よげんの書」
      • 提供したい価値を抽象化したプロダクトビジョン
  • ロードマップの策定
    • 具体化するフェーズと抽象化するフェーズを行き来する
    • 事業計画を因数分解し、優先順位を付ける
      • やらないことを明確に
      • バリュープロポジション内でも優先順位を決める
  • ロードマップの課題とそれに対する運用
    • 関係者が多く、プロダクトの在り方や目指す姿、最新のロードマップがわからない
      • 最新のロードマップの場所を固定化し、月1回の全部署誰でも参加可能な議論タイムを設けた
    • プロダクトが大きくなり、異なる目標を追いかけるチームの要望をうまく扱う必要が出てきた
      • セールス・CSそれぞれバックログを分けた
      • POがそこから実際に取り扱う順番を決めている

エンタープライズSaaSの初期成長戦略

  • POが思い描く世界観を実現したい顧客を探す
    • 通常の受託開発とは異なることを理解してもらう
      • 個別要求に答える場合もある
        • 汎用的な機能はSaaSに取り込む
        • 個社に特化したものはあくまで機能外のものとする
        • 一旦個社の機能として対応してから汎用機能化する場合などもある

急成長なフェーズでの成長戦略

  • ロードマップで実現したいことはコンテキストで変わる
    • 未来予想
    • 工数管理・リソースの可視化
    • 計画を立てて機会損失をなくす
  • ロードマップ文化が定着した背景
    • メンバーが増えたことで難しくなった事業・部署間連携のため
      • ビジネスチームが売りたいものとエンジニアが作りたいものが乖離していた
      • 成長ファクターが一部の人間に集中し、リスクとなっていた
    • 新規開発、追加開発、改善や技術的負債回収のいずれかによって異なるスケジュール感
  • ロードマップ作成の流れ
    • 達成するべき売上・リリース日がトップダウンで決まる
    • 事業課題を小課題に分解し、コスト計算
    • ステークホルダーとの意思決定、スケジュールの打診
    • Qが始まる3ヶ月前から、Qの開始から半年分のロードマップを引き始める
      • 20%のバッファを設けた状態で引く
  • 運用時に出た課題
    • 差し込みが入って進まない
      • 予想可能なものはロードマップに組み込む
      • 予測不能なものはその内容によっていくつかの対応がある
        • 次に同じことが起きた場合に備えたドキュメント化
        • バッファを一定設けておく
    • マイルストーンやスケジュールが引けない
      • はじめてだと精度は50%くらい
      • 実際に発生した工数を管理して運用しながら精度をあげる
      • ある程度の係数を設けて見積もる
      • 複数人で見積もりをする

アルプのロードマップ変遷

speakerdeck.com

  • 仮説検証フェーズではロードマップはあまり参照されなかった
    • 半年くらいの目標はあったが、顧客のニーズに合わせて変化していた
      • 追いかけるための目標としての信頼感がなかった
      • エンジニアはあまり気にしていなかった
    • 作ってみないとわからないフェーズではロードマップよりもなぜ作るのか?が知りたい
  • プロダクトの方向性が定まった上で、それを伝える手段としてのプロダクトビジョン
    • プロダクトビジョンからトップダウンでロードマップを決める
    • 組織間でプロダクトビジョンを達成するための共通認識としてのロードマップ
  • ハイインテグリティーコミットメント
    • わかる/できる前に求めない
      • 誠実な時期を伝えるための情報収集・整理
    • 開発チームに驚きがない状態で方針を決める
    • できるだけ納期はコミットしない
    • コミットメントを小さく、納得感のあるサイズにする

感想

  • プロダクトのビジョンとロードマップの接続がわかりやすいかで組織の納得感が変わってきそう
    • 組織が方向性を揃えて連携するためのロードマップ
    • 現在のビジョン・ロードマップから未来の姿を思い描けているか?
  • 必要としているロードマップのコンテキストについてあまり意識したことはなかった
    • 複数のコンテキストを統合して1枚のロードマップとして表現する場合もありそう
  • ロードマップの精度を上げるために開発に提供してほしい情報はどういうものなんだろう
    • 予測不能なものから予想可能なものを切り出して、わからないものを小さくするとか
    • やはり実工数の計測は必要かもしれない
  • 仮説検証フェーズでのロードマップは引いても気にされないし、信頼もされないのはなんとなくわかる