30歳からのプログラミング

タイトル通り、Rubyを使ってRubyインタプリタを作っていく面白いテーマの本。
プログラミング初心者も対象読者に入っているため、非常にコンパクトにまとまっており、140ページ程度でインタプリタを作れる。

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門（紙書籍＋PDF版）www.lambdanote.com

Rubyの入門から始まっていくが、本当に最低限の機能しか扱わない。
クラスやオブジェクトという概念は全く出てこないし、メソッドもほとんど出てこない。
初心者のために内容を厳選したということだろうが、かなり思い切った構成になっている。

しかし、そんな「最低限の内容」だけでインタプリタ自作のような複雑で面白いことをやれるのが、興味深かった。

出てくる内容が、変数、条件分岐、配列、ユーザー定義関数、といったものばかりで、「本当に初心者向けだなー」と思いながら読んでいた。
そしてその「初心者向け」の機能だけでインタプリタを作っていくのは本当に面白かった。
言語機能について説明した後、それを使う機会（インタプリタ実装）がすぐに訪れるのも、入門書の構成として良いと思った。

Rubyの言語機能の説明もそこそこに木構造の説明に入っていく本書は、プログラミング入門書としてはかなり独特だと思う。
全編に渡り木構造や再帰を使っており、以前読んだ『プログラミングの基礎』に似ているかもしれない。

薄くてカラフルなのも、入門書として素晴らしいと思う。全ページフルカラーになっている。

特に、抽象構文木をカラフルな図で表現してくれるのは素晴らしかった。
これのおかげで、扱っているデータの構造をビジュアルで理解できるし、実装すべき処理もすぐにイメージできる。

本書の担当編集者であり、出版元のラムダノート株式会社の創業者でもある鹿野さんが、プログラムによって木を描いていたらしい。 note.golden-lucky.net

こういった工夫のおかげで、プログラミング初心者でも学習を進めやすい内容になっていると思う。

とはいえ、本当の初心者よりも、インタプリタや抽象構文木、言語処理系といったものに興味のある人が本書のメインターゲットだと思う。
すごく簡単に、インタプリタや言語の実装という世界に触れることが出来る。

かなり初歩的な内容ではあるが、文字通り初歩、最初の第一歩にはなる。
パースとか抽象構文木とか、何となくで理解していた用語の概要をきちんと知ることが出来た。
「パースする」といったときに何が行われているかを、何となくイメージできるようになった。

実際の言語処理系はもっと複雑なものだろうけど、やっていることをイメージできる、概略を掴める、というのが最初の一歩として重要だと思う。

本書では構文解析は行わず、著者が作成し gem として提供されているライブラリを使う。
読者は、構文解析済みの抽象構文木を対象に、それを処理するためのプログラムを書いていく。
他にも要所要所でそのライブラリに作業を丸投げするが、それは決して本質を損ねるようなものではない。
むしろ「インタプリタづくり」という本質に集中できるよう、本書のテーマにおいては非本質的な諸々の作業を肩代わりしてくれていると言える。

以下、各章のメモ。

第1章

本書では、Rubyを学ぶための題材としてRubyインタプリタを作る
本書で作るのは、最低限の機能のみを持った、MinRubyと名付けられた言語のインタプリタ
Rubyインタプリタとは、Rubyで書かれたプログラムを実行するプログラム
RubyインタプリタもまたRubyで書かれたプログラムなので、動かすためにRubyインタプリタが必要
そのため、本物のRubyインタプリタをコンピュータにインストールし、それによってMinRubyインタプリタを動かし、そのインタプリタが四則演算などのMinRubyプログラムを実行する

第2章

変数、分岐、ループなどの基本的な概念について学ぶ

第3章

インタプリタを作るために、木というデータ構造を学ぶ。なぜなら、プログラムのような複雑なものを扱うのに適したデータ構造だから。
Rubyの「配列」で木を表現し、Rubyの「関数」で木を操作する

第4章

まずは四則演算のみをサポートしたインタプリタを作る
プログラムはただの文字列なので、まずはそれを木構造に変換する必要がある。この変換のこと構文解析、あるいはパースと呼び、それによって得られた木を構文木と呼ぶ。
括弧や空白などの不要な情報を省いた構文木を抽象構文木という
プログラムを受け取る　→　構文解析して抽象構文木にする　→　関数で木を操作する　というのが処理の流れ
四則演算の場合、木の葉についてはその値を返し、木の節については2つの部分木の実行結果を演算子に従って計算する

第5章

複数の計算式を並べたものを複文という
プログラムが計算式と大きく違うのは、複文になっていること
だからインタプリタも複文に対応させる必要がある
whileを使って複文に対応する
インタプリタに変数を覚えさせるのは、Rubyのハッシュによって実装する

第6章

実装しようとしている言語をターゲット言語、インタプリタの実装に使っている言語をホスト言語という
インタプリタの本質は、ターゲット言語の言語機能をホスト言語の言語機能に丸投げして、そちらで処理すること
本書の場合はMinRuby（ターゲット言語）の処理をRuby（ホスト言語）で実装している
構文解析の段階で他の言語機能を使ったプログラムに置き換えて扱うものを、糖衣構文という

第7章

関数の実装は、変数と同じようにハッシュを使ってインタプリタに覚えさせる
「言語仕様」とインタプリタの「実装」は一致するとは限らない。プログラミング言語を学ぶときはそれを注意して、「実装」ではなく「言語仕様」を学ぶことが大切。

第8章

関数の実装を拡張して、ユーザー定義関数をサポートする

第9章

言語Xのインタプリタに必要な機能を言語Xだけで実装できれば、インタプリタを使ってそのインタプリタ自身を動かせるようになる。これをブートストラップという。
前章まででMinRubyインタプリタに様々な機能を実装してきたので、あとは配列とハッシュを実装すればブートストラップが可能になる
データ構造をつくる記述を構築子という
MinRubyの配列の構築子とハッシュの構築子は、Rubyの言語機能をそのまま使う

同僚に借りて読んだ。

ソフトウェア開発者を対象に、チームのなかでどのように振る舞うべきか、どのようなチームにしていけばいいのか、チームを守るために何をすべきか、チームリーダーの役割とは、といったものを説いていく。
非常に有名な本で、自分もタイトルだけは知っていた。
本書で紹介されているHRT（謙虚、尊敬、信頼）という概念も有名で、求人ページの「求める資質」でHRTが挙げられることもある。

翻訳が上手く、ページ数も少ないので手軽に読める。

www.oreilly.co.jp

有名な本ではあるが、「人に親切にしろ」「正しく振る舞え」といったことを主張してくるようなものをイメージしていて、あまり興味がなかった。
「義務」を説いたり、「チームのために身を粉にしろ」と主張したりして、「プログラマとしての在るべき姿」を主張しているのだと思っていた。

だが実際はそうではなく、あくまでも自分（やチーム）が幸福になるためというスタンスで書かれており、意外だった。
「こうすべき」という振る舞いが色々と書かれているが、それは何も品行方正になれということではなく、それをやることで成功や幸福に近づけるからやりましょうというロジック。

本書に書かれてあるのは面倒くさいこと、大変なことばかりだが、好きなこと（ソフトウェア開発）に多くの時間を割くためにはこれがベストだという。
HRTをベースにした振る舞いを心がければ、社内政治や衝突や人間ドラマに時間を割かずに済む。

成功するためにも、コミュニケーションやチームワークは重要になる。
ソフトウェア開発はチームスポーツであり、それが生産性や効率性を左右するから。

プログラマが、幸福や成功のために重要な「他人とのコミュニケーションやコラボレーションの能力」を高めることが、本書の目的。

しかしそうは言っても、本書の内容はなかなか実践できるものではない。
自分さえ頑張ればどうにかなるものでもない。

言っていることは分かるが現実的ではないのではと思っていたが、翻訳者のインタビュー記事を読んで納得できたかもしれない。

もし相手を信頼できなかったとしても、それをそのまま口に出して言う必要はないですよね。心の中で思うのは自由だけど、仕事としては割り切ってHRTやりましょうっていうことだと思います。

天才でなくていい！『Team Geek』訳者・角征典と考える、チームに貢献するエンジニアの気配り力 - エンジニアHub｜若手Webエンジニアのキャリアを考える！

HRTを、仕事のためのスキル、仕事を円滑に進めるためのインターフェイスと捉えている。
確かに「HRTを大切にしよう」と無理をするより、「仕事の一環としてのHRT」と割り切ったほうが、自分の中で受け入れやすいかもしれない。

以下、各章のメモ。

1章

偉大な仕事は一人では出来ない
リーナス・トーバルズは一人でLinuxを作ったのではない
- リーナスの本当の偉業は、Linuxを開発したことではなく、Linuxの開発という巨大なプロジェクトをリードしたこと
成功を手にするためには他者との協業が必須。我々は一人でなんでも成し遂げられる天才ではないのだから。
一人で仕事をするのはリスクが高い
- 間違いに気付かない、気付くのに時間がかかる
- スピードも遅い
ソフトウェア開発はチームスポーツであり、成功の鍵は高機能なチームにある
チームで働く時の原則はHRT。謙虚、尊敬、信頼。
- まずは自分自身がそれを実践し、それをチーム、組織、ユーザーへと、広げていく
相手を尊敬し建設的な批判をすることが大切。自分だけではなくチーム全員がそれを理解していないといけない。
自分の書いたコードと、自分の人格を、切り分ける。これは自分に対してそう考えるべきだし、他者に対してもそう考える。人格とコードは別。
- 議論しているのはコードのことであり、誰かのコーディングスキルや価値のことではない
尊敬が欠けている指摘は、相手を感情的にさせ、必要以上に防御的にしてしまう。誰も得しない。
過ちから学ぶためには、失敗を文書化することが大切。ポストモーテム。
- これは、謝罪や言い訳を羅列するものではない。何を学んだか、何を変更するか、を書く。
間違いや能力不足を認め、弱さを見せることで、長期的には立場は向上する。尊敬を得られる。

2章

メンバーがチームの方向性を正確に理解するためには手間がかかるが、チームの生産性や幸福のためには必要な投資
ミーティングなどの同期的なコミュニケーションではなく、メールなどの非同期なコミュニケーションを増やすのが原則
- ドキュメントから全ての情報を得られるようにすべき
ミッションステートメントを定めて、プロダクトのスコープを制限する
- 集中するためには、何をやらないか決めるのが大事なのだから
何をどうしたいのか書いた設計文書。それが、優れたプロダクトや実装につながる。
設計文書は、プロジェクトの進行に合わせて変化していくべき
議論のアーカイブがどこかにあることで、検索可能になる

3章

リーダーはチームのために道をつくり、チームの安全・安心に気を配る。全てはチームのニーズを満たすため。
サーバントリーダー。リーダーは、執事や召使いのようにチームに奉仕する。
人は、自分が扱われるように振る舞う。そのため、メンバーを子供や囚人のように扱えば、彼らはそのように振る舞う。
チームの合意形成や方向性の決定を支援するのが、リーダーの役割。目標の達成方法は、プロダクトを作る人たちが決める。
メンバーに相談されたら、リーダーはメンバーの代わりに問題解決するのではなく、メンバーが問題解決できるように手伝う。そのためには質問することで問題を整理するのが有効。
リーダーは障害を取り除くための答えを知っている必要はなく、取り除ける人を知っていることに価値がある
チームに安心感を与えてリスクを取れるようにすべき。そうすることで成功率が高まる。
安心感を育てるためには、失敗を許容することが大切。個人ではなくチームとして失敗し、そこから学んでいく。
チームの方向性と目標を明確にして、あとは自律性に任せる
エンジニアによって必要なものは異なる。それを把握することが大切。
内発的動機には、自律性、熟達、目的の3つが必要。給料に不満がないという前提だが。
プロダクトオーナーシップを感じることが出来れば、モチベーションにつながる

4章

本書では分かりやすさのために「有害な人」という言葉を使っているが、排除すべきは「有害な振る舞い」であって人ではない
好ましくない振る舞いが続けば、生産性が落ちるだけでなく、チームの文化そのものが悪化していく
有害な振る舞いは、チームから注意と集中という貴重なリソースを奪う。ソフトウェア以外のことにそれらを浪費させられてしまう。
貴方の仕事は優れたソフトウェアを作ることで、訪問者の機嫌を取ったり自分のこれまでの行為を正当化したりすることではない。

5章

悪いマネージャーの特性
- 失敗を恐れ、リスクを回避する
- 自分の立場や地位のために情報やコミュニケーションチャネルを占有しようとする
組織内で戦うときは、勝てる見込みのある重要な争いを選択する。勝てない争いで社内政治のための資本（政治資本）を消費してはいけない。
エンジニアはプロダクトのローンチにエネルギーを注ぐべき。ローンチこそが、信頼、名声、政治資本の増加につながる。
仕事には、UIの改善などユーザーに見える「攻撃的な仕事」と、リファクタリングなどの「防御的な仕事」がある。
- 「防御的な仕事」はいくらやっても評価されず、そればかり行うのは政治的な自殺行為。最悪の場合、プロジェクト自体が中止に追い込まれてしまうかもしれない。
積極的に人に親切にすると、自分に返ってくる
昇進することで、自分の運命をコントロールできる度合いが高まる
多忙な「偉い人」にメールを送るときは簡潔に。（最大）3つの箇条書きと、1つだけの行動要請を書く。
悪い組織からは逃げることも出来る。選択肢を知ることで、自由になれる。

6章

ユーザーのいないソフトウェアを開発しても意味がないし、成功できない
人間は論理だけでなく感情でも判断する。ユーザーの感情に注意を払わないといけない。マーケティングは感情操作のテクニックであり、重要。iPhoneはAndroidに比べてそれに成功している。
「小さく約束して大きく届ける」が基本
UIを洗練させる、サインアップしなくても使えるようにする、読み込みを速くする、など第一印象をよくすることが大切
速度は機能の一つ
成功しているソフトウェアというのは、問題を限定してそれを上手く解決したもの。あらゆる問題を下手に解決するのではなく、多くのユーザーの共通した問題を上手く解決している。