Blogs

「Go言語でつくるインタプリタ」を読み終えました。

この本は、私のようなGo言語初心者のでも理解しやすい構成で、プログラミング言語の構築に必要な字句解析や構文解析の基本的な概念を学びながら、動くインタプリタを完成させることができます。 プログラミング経験があるものの「字句解析」や「構文木」という用語はなんとなく聞いたことがある程度だった私にとって、実際に手を動かしてプログラムを動作させることができ、学びと共に達成感もひとしおの一冊でした。

多くのハンズオン本では、「インタプリタの一部だけ」を実装することに留まりがちで、最終的に完成するのが部分的なコードであったり、動作しない例も多くあります。 しかし、この本は最初から最後まで実際に動くインタプリタを作り上げることができ、その後にいろいろ試してみたりもできます。 実際私はREPLだけでなく、ファイルを読み込んで実行させるように改造して楽しみました。 このような「動くものを作り上げる」体験は、プログラミングやシステム理解にとって重要なポイントだと思います。

具体的には、以下のようなセクションごとの段階的なステップを経て、コード全体が構築されていきます。

字句解析: 「トークン」や「字句解析器（Lexer）」という基本的な概念から始まり、最初のコードの実装を通してデータがどのように分解されるのかが明確になります。

構文解析: 「構文解析器（Parser）」を使ってAST（抽象構文木）を生成することで、プログラムの文法構造がどのように理解されるかを深く掘り下げます。

評価器: 最後に、構築したASTを評価し、インタプリタとして動作する一連のフローを構築していきます。

Go言語初心者でも学びやすい理由の一つに、各章でのコードと概念の説明が一貫して丁寧に行われている点が挙げられます。 例えば、字句解析の章では一つひとつのトークンの分解と構造を詳しく説明しており、構文木（AST）の組み立ての理解が進むような工夫がされています。 構文解析や評価に進むに従い、少しずつ難易度が上がりますが、各章で順を追って理解していけるため、初心者にとっても安心です。

また、テスト駆動開発であることも理解が非常に進みました。 私は普段コードをあまり書いていないので、テスト駆動開発の恩恵に預かれていなかったのですが、先にどういうアウトプットが想定されるかが提示されるのは理解の助けになりました。

時間はかかりましたがなんとか読破できましたので、個人的なおすすめの読み方を提示しておきます。

コードを写経する

手を動かしてコードを書くことは、多くの人にとってこの本を読む上では必須だと思います。手稲にコードが記載されていますが、それでもぼんやり写経してると飛ばしたり書くところを間違えたりして、それを解消するプロセスがまた理解につながったりします。 電子書籍だとコードをコピー&ペーストできてしまうこともありますが、ここは実際に自分の手で入力して試行錯誤するのがおすすめです。

理解のズレに注意

インタプリタの実装は、エラーが起こりやすい分野でもあります。 例えば、字句解析のセクションではトークンの扱いを間違えやすく、構文解析ではASTの構造の間違いが結果に影響します。 実行時にエラーが発生した場合、なぜそのエラーが起きたかを丁寧に追っていくことが大切です。 その点、ユニットテストも提示してくれているところは非常にありがたいです。ユニットテストを頼りに自分の理解を補強することができます。

各章ごとに振り返る

一気に読み進めず、各章で実装した機能がどのように働くのかを自分なりに理解する時間を取ることをお勧めします。各章が次の章の基礎になるため、途中で理解が浅い部分があると後の章でつまづきやすくなります。

総評

「Go言語でつくるインタプリタ」は、Go初心者から中級者に向けた実践的な内容で、言語構築の基礎を学びたい方に非常におすすめの一冊です。 特に、プログラムが動作し、抽象的な概念を実際の動くコードとして実現できる達成感を味わうことができます。 字句解析や構文木のような「聞いたことはあるけれど、実はよく知らない」という分野に一歩踏み込めて、さらにGo言語の勉強にもなる本書は、自分のレベル感にはちょうど良い一冊でした。 ちなみにジェネリクスは無い時代の本なので、その辺を改良するのも良い勉強になるかもですね。

また、本書には続編があります。 https://compilerbook.com

今度はインタープリターではなくコンパイルして仮想マシン上で動作させるそうです。 こちらはまだ日本語訳されていませんが、時間を見つけて取り組んでみたいと思います。

2年間履修した帝京大学の科目履修生コースを終えました。今年も引き続き科目履修生として登録するか、正科生への切り替えを検討していましたが、家庭の事情やら仕事の忙しさもあり、今年はこれまで学んできたことの復習を隙間時間に独学でやっていこうという事にしました。

一区切りということで2年間の科目履修生を振り返ってみたいと思います。

履修科目

2020年度履修科目

• 論理数学
• 数理統計学
• 離散数学
• オートマトンと計算理論
• コンピュータネットワーク
• データ構造とアルゴリズム

平日の仕事終わりや土日の多くの時間は授業を受けたりレポート書いたりしてました。仕事は比較的早めに上がれたのと、家族の協力あってのことでした。

おかげさまで全部単位は取れましたが、統計学が痛恨のC評価で、一番勉強した科目だったのですがセンスのなさが露呈しました。

年度の前半でほぼ試験も終わったので、詰め込めばもっと受けられたと思います。とはいえ1年に10〜15科目くらいが限界かなと思います。ちなみに暇だった年度の後半は勉強熱が高まっていたので、AWSの資格試験をバンバン受けてました。

2021年度履修科目

• オペレーションズリサーチ
• コンピュータシミュレーション

2年目は2教科履修しました。2年目に教科数を減らしたのは仕事が忙しくなりそうと予想したからで、案の定忙しくなったので2教科にしておいてよかったです。この年も年度の前半でほぼ授業は終わりました。後半は仕事に追われてました。

授業の感想

レポートも細かいところまでしっかりみてもらえ、赤ペンでいっぱい書き込まれたフィードバックをもらった時は、間違えた気恥ずかしさはありつつもやってよかったなと思えました。 メールで何度か質問させてもらいましたが、こちらも丁寧に回答いただきました。

テストはコロナ禍と言うこともあり全てオンラインで受けました。なので本当にリアルでの大学生活は皆無でした。通信大学とはいえテストくらいは大学生気分を味わえると思っていたのですが、まぁ仕方がないですね。

お金に見合った価値があったかと言われると、自分の場合はあったと言い切れます。 ただ、大学は通えば良いというものではないことは、義務教育・高校・大学と進んだ若かりし頃を思えば想像ついていましたし、多くの方も実感としてあるのではないでしょうか。そこでどのように振る舞うかが重要です。単位はもちろん取れたら嬉しいですが、単位を取るためだけを目的にしていたら、あまり価値はないものになるでしょう。

仕事に好影響を与えるかと言われると微妙です。SREとして従事している今の仕事に直接影響はなかったかなと思います。そもそも自分の場合は仕事に生かすというよりかは、今従事しているコンピュータというお仕事の根幹をなす学問領域に興味があったというのが動機でした。

ただ、オンプレの経験がある人がパブリッククラウド上でのインフラ構築時に勘所に優れていたり、低レベルなプログラミング言語を操っていた人が高水準のプログラミング言語でも優れた能力を発揮されているケースを何度かみてきました。コンピュータサイエンスのような低レベルな知識が間接的にコンピュータに携わる上で好循環を与えるのかなとも考えています。

これから

冒頭にも書きましたが、今年は独学でコンピュータサイエンスを学んだりしながら授業で習ったことを今一度復習したいなと考えています。本当にたくさんの事を知らないんだなと痛感することができました。仕事やプライベートに余裕が出たら改めて門をたたきたいと思います。

ここ数年HHKBをずっと使っていて、非常に気持ちよく利用しています。巷の噂に違わず入力するのが気持ちよくなるキーボードです。

ヘビーユーザーの証の一つである尊師スタイルの存在は以前から知っていて憧れがありました。ただ自分はHHKBを机に置いたノーマルなスタイルで利用することが多かったため、踏み込んでいませんでした。

そんな自分が尊師スタイルに入門したきっかけや感じたメリット・デメリットを記しておこうと思います。これからHHKBを購入するか迷っている人、尊師スタイルに憧れている人の参考になればと思います。

きっかけは在宅続きの運動不足からスタンディングデスクでPCを利用したくなったところから始まりました。私の場合は予算の関係上Moft Zを利用したスタンディングデスクを導入しました。1万円以内でスタンディングデスクが導入できるので非常にお得です。

Moft Zを利用する場合、MacとHHKBを両方置くスペースは流石に無く、キーボードはどうしてもMacのものを利用することになります。キーボードの打鍵感もさることながらバッククォートの位置がMacのキーボードとHHKBで異なることにストレスを感じるようになりました。最近はドキュメントを書く時やSlackでコミュニケーションするときもインラインコード入力時にバッククォートを使うことが多いです。

スタンディングデスク利用時のキーボード入力にストレスがあると、健康のためというだけではだんだんやらなくなるのは目に見えていました。せっかく買ったMoft Zも無駄になり、座りっぱなしの日常では不健康まっしぐらです。

そこで思いついたのが尊師スタイルです。尊師スタイルであればスタンデイングデスクの時もHHKBをMacの上に置けるのでストレスから解放されます。私のような理由以外でもただ単にカッコ良さそうとか、デスクのレイアウトの関係上尊師スタイルが向いている方もいるかと思います。自分なりに尊師スタイルのよかった点と悪かった点をまとめてみました。

メリット

一番の目的としていた入力インターフェースがHHKBに統一される点は、想像以上に快適でした。効率化は計り知れないと感じます。おかげで当初の目的であるスタンディングデスクでの作業も快適です。

デメリット

TouchIDが使えない

Macの場合Touch IDがキーボードブリッジに覆われてしまいます。PCログイン時やサイトのパスワード入力時に重宝していたTouch IDが使えなくなるのは思ったより痛手でした。Touch ID付きHHKBが出たら即ポチってしまいます。が、今は大人しくパスワードを入力するしかないですね。Apple Watchを持っている方ならMacへのログインはApple Watchが補助してくれます。

持ち運びが不便

これでどこでも尊師スタイルでHHKBと一緒と思いきや、HHKB、キーボードブリッジ、パームレストの3点セットを持ち歩くのはやはり面倒でした。コーディングならいざ知らず、ちょっとした作業や買い物をする際はTouchIDが使えないことも相まって面倒さが増します。 いい感じのキャリングケースがあれば緩和されるかもしれません。

尊師スタイルに必要なもの

尊師スタイルに必要なものも挙げておきます。

• キーボードブリッジ
• セパレート式パームレスト

キーボードブリッジが無くても置き方によってはいけそうな気もしましたが、注意深くキーボードを置くのは面倒なのでお金で解決しました。また、MacのTouchPadを使うのであればセパレート式のパームレストも必要です。

まとめ

ちょっぴり憧れだった尊師スタイルに入門できただけでも良い経験でした。この調子でHHKB沼へどんどんはまっていこうと思います

1年ほど積読にしてた「入門監視」を読み終えました。

この本は監視ツール個別の話はほとんどなく、監視をどう設計すべきかが記されています。 私自身、監視を色々見たり設定したりしてきましたが、考え方の答え合わせができて楽しかったです。

まずはアンチパターンをチェックする

この本を買う前に1章だけでもみてもらって、自分がアンチパターンにハマっていないかを是非チェックして欲しいと思います。

流行りのツールにOSメトリクスでとりあえずアラート仕掛けたりしていた自分には胸をえぐられる章でした。 心当たりのある人は目次を見ただけでもグッとくると思います。

 1.1　アンチパターン1：ツール依存
    1.1.1　監視とは複雑な問題をひとくくりにしたもの
    1.1.2　カーゴ・カルトなツールを避ける
    1.1.3　自分でツールを作らなければならない時もある
    1.1.4　「一目で分かる」は迷信
1.2　アンチパターン2：役割としての監視
1.3　アンチパターン3：チェックボックス監視
    1.3.1　「動いている」とはどういう意味か。「動いている」かどうかを監視しよう
    1.3.2　アラートに関しては、OSのメトリクスはあまり意味がない
    1.3.3　メトリクスをもっと高頻度で取得しよう
1.4　アンチパターン4：監視を支えにする
1.5　アンチパターン5：手動設定

自分の経験を答え合わせをする

自分はこれまでWebシステムを中心に監視の設定を見たり行ったりしてきました。 世の中には色々なシステムがあり、色々な事情もあるとは思いますが、これまで経験してきた監視の経験を本書で答え合わせをしてみました。

所属組織の標準的な監視パッケージに乗っかったこともあれば、自分で1から設計したこともあります。

どこかで見聞きしたものなのかも忘れましたが、自分で監視を設計するときは下記のポリシーを大切にしてきました。

• 利用者より先に気づく事
• ユーザーの実際の不便を監視する事

「動いている」を監視する

サービスが元気に動き続けることがベストではありますが落ちることも必ずあるのがシステムの世界です。そんな時にサービスの不調にいち早く気づくことが監視の一番の役目であると考えています。

なのでURL監視を中心とした監視を組みつつ、可能であればビジネス的に一番熱いユースケースやユーザーの不便に最もつながりそうなユースケース、 つまりユーザーの信頼を失うことにつながりそうなユースケースを実際にトレースするような監視を作ってきました。

また、この監視が動いていればとりあえずシステムとしては健全であるというラインが担保できていると、システム運用にかかるストレスが非常に低減されます。

例えばポイント系のシステムでポイント付与までのユーザーの行動をトレースするようなものを、ユーザー登録が命のようなサービスであれば実際にユーザー登録を行うようなものを外部から実際に自動的に行うような監視を行ったりしました。

なので本書でいう「動いている」を監視できていたと思います。

お手製の監視システムでOSメトリクスを監視

一方で、OSのメトリクスに関してはついついCPU 80%とかロードアベレージ10とかを閾値とした監視を手癖のように設定しがちではありました。振り返ってみてもCPUやロードアベレージなどのメトリクスによるアラートにより実際に行動を起こす事は少なく、 URL監視などの外形監視の補助として使うことが多いです。

そして監視ツールの選定ですが、監視Saasが成熟してきている今日、未だに本格導入を試みたことがありません。AWSだとCloud Watchをベースにした監視などを行ったことはありますが、当時はカスタマイズ性にいまいち満足がいかなかったという記憶があります。 そういった古い記憶から無意識に監視Saasそのものを敬遠しがちになっていたのは否めません。

直近ではPrometheusを導入して、それはそれで満足はしていますが、同じことを監視Saasでやれなかったとはいえません。監視Saasも時が経つにつれ洗練されているはずで、コスト対効果を鑑みてもっと積極的に導入を考えても良かったと反省する部分もあります。

この辺りは本書でいうアンチパターンにハマっていたと思います。

まとめ

自分の経験を本書と照らし合わせて答え合わせのできる楽しい読書でした。

監視は作り手の自由度が高い分野であると思います。下手をするとアラートだらけになってしまう所を本書の指針に沿って設計する事で、みんなが幸せになれる監視を設計できるかと思います

Pythonプログラミングイントロダクション(20章) まで読みました。 20章はベイズ統計についです。

スパムフィルターでおなじみベイズフィルターですが、ベイズ統計を理解する上で重要な条件付き確率に関して問題が出ていました。

本書ではベイズ統計に関する例を取り上げつつ、Pythonで実装を提示してくれています。 そこは本書をみていただくとして、条件付き確率の問題について取り上げたいと思います。

条件付き確率

本書掲載の問題は下記になります。

あなたは森の中を歩き回り,美味しそうなキノコの群生を見つけた.
カゴいっぱいにキノコを採り,家に帰って旦那様のために,キノコ料理の準備を始める.
しかし,調理を始める前に,彼はあなたに,野生のキノコが毒キノコかどうかを本で調べるようにお願いした.
本によると,おしなべて野生キノコの80%は毒キノコとのことだ.
あなたは手元のキノコを本の中の写真と見比べ,95%の割合でそれが安心して食べられるキノコと判断した.
あなたはどの程度安心して,キノコ料理を旦那様に作ってあげられるだろうか.

採ってきたキノコが毒キノコの確率は80%になります。なので毒キノコで無い確率は20%です。これをP(B)とします。

写真をみて95%の確率で毒キノコで無いと判断していますが、実際採ってきたキノコが毒キノコの場合とそうで無い場合で、写真から判定される確率は異なると思います。 つまり写真と見比べて毒キノコで無いと判断した際の確率P(A)は毒キノコを採ってきたかそうで無いかという確率P(B)と独立でないと考えます。

仮に独立だとしても P(A) = P(A|B)です。

仮に、とってきたキノコが毒キノコで無いという条件のもと、写真と見比べた結果毒キノコで無い確率を95%とした場合、 採ってきたキノコが毒キノコでなく、写真で判断しても毒キノコで無い確率はいくらになるでしょうか。

写真判定シロ かつ 採ってきたキノコは毒でないを求めたいわけです。式で表すと

P(A)とかP(B)を使うと

つまり19%の確率で毒キノコではないということになります。

あなたは食べますか？

僕は食べません。

まとめ

条件付き確立の問題について取り上げてみました。 ここまでの章で学んできた頻度統計学とは一線を画するベイズ統計について興味を持たせてくれる章でした。