kenju's blog

About Programming and Mathematics

"Teach Yourself Programming in Ten Years" と技術との付き合い方

http://norvig.com/21-days.html

"Teach Yourself Programming in Ten Years" というエッセイがある。Peter Norvig という America のエンジニアが書いたエッセイで、界隈では有名だったらしい。ひょんなことからこの存在を知った。

So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours or 21 days. How about working hard to continually improve over 24 months? Well, now you're starting to get somewhere...

最近、技術との付き合い方を考えることが多かった。自分は好きなものを見つけたら、他のものを忘れてとことん追求してしまうたちなので、自分はそれで楽しいのだけれど、プライベートや仕事上のタスクの優先度などを考慮して振る舞わないといけない場面も多い。そんな中で自分の知的好奇心を失わずに賢く振る舞いたい、そのために限られた時間をなにに、どう工夫して割くか、と考えることが多かった。

結局、数時間や数日で習得できる知識って、長くても2,3 年で陳腐化してしまうし、1,2 回くらいしか役に立たない。確かに、新しいことを学び続ける楽しさはある。しかし、単純な記憶ゲームになってしまうと、人生の消耗でしかないし、そこに知的創造性はない。

であるから、本質的な、普遍的な知の探求というのは、10 年スパンで進んでいくものといっても過言ではない。10 年後の世界は、どうなっているだろうか。全く想像はつかないけれど、少なくとも一言語の一過性のある技術やフレームワークとか、今広く使われているサービスとかが残っている可能性は限りなく近いと思う。RubyAWS はまだまだ生き残っているかもしれないけど、今日の姿とは全く違うだろう。

表面的な知識を習得するだけで満足している人生もつまらないし、エンジニアとしての伸び代もストップ高だろう。

週末に技術書を整理しながら、つれづれとそんなことを考えていた。有意義な週末だ。

『コンピュータアーキテクチャ改訂4版』を読んだ

コンピュータアーキテクチャ 改訂4版

コンピュータアーキテクチャ 改訂4版

普段の仕事では高水準言語を書いているばかりであり、PC(program counter) や IR (instruction register)がどう関与して命令コードを実行しているかとか、割り込みがどのようなフローで発生するかとか、SISD/SIMD/MIMD それぞれの Pros/Cons って一体なんだろうといった知識は意識的に習得しないといけないとずっと思っていた。大学の講義の教科書で利用しているということで、ひとまず通読した。

さすがに大学の教科書として使われているだけあって、説明が丁寧で、入門として非常にわかりやすかった。丁寧に描かれた図や表も豊富にあり、理解を助ける一助となった。コラムや参考文献の情報も豊富にあり、とっかかりとして読むのには最適な本だった。

『Understanding Computation』を読んだ

実際に読んだのはだいぶ前のことだけど、思い出したように記事に起こしておく。

決定性有限オートマトン・非決定性有限オートマトンの話から始まり、決定性/非決定性プッシュダウンオートマトンチューリングマシン、ラムダ計算やコンビネータの話へと展開されていく。

本書が非常に読みやすかったのは、Ruby でサンプルコードを紹介しながら進めていく点だ。理論とコードを適切に行き来しながら説明することで、説明がすっと頭の中に入ってきた。

有限オートマトンを用いて正規表現を実装してみたり、プッシュダウンオートマトンを用いた字句解析・構文解析の例も紹介することで、それら計算機モデルが現実世界でどのような課題を解決するのかへの理解も深めることができた。

今後新しいプログラミング言語を勉強するときの、練習材料としても本書のサンプルコードを元に移植してみるネタとしても良い。

良い本でした。

サンプルコード

https://github.com/kenju/understanding_computation

『Amazon Web Services 定番業務システム 12 パターン設計ガイド』読書メモ

Why reading this book?

今のチームになってから、仕事で AWS の各種サービスの特性を生かしたログ基盤の設計やアプリケーションを作成する機会が増えてきた。Kinesis Streams や DynamoDB/DynamoDB Streams, Lambda や Redshift など、なんども使用して慣れてきたサービスが増えてきた一方で、AWS のサービス群を俯瞰して整理したいと思うことがあった。

今週は、設計パターンを浅く広く振り返りたい&情報蒐集したいという気持ちになったため、読んでみた。これはその備忘録。

Chapter 1. Web System

Pattern 1. Campaign Site

VPC 内に EC2 instance をたて、Gateway では Route53 でルーティングし、EC2 には EBS を仮想ストレージとして attach するパターン。最小限の構成で、普通の LAMP application や簡単な業務システムを構築するときの、基本パターン。

Pattern 2. Corporate Site

EC2 instance を ELB で冗長化したり、CloudFront 経由で S3 にある静的コンテンツを配信したり、RDS をそれぞれの別の AZ に Master/Slave でレプリケーションしたり、といった冗長化の観点をさらに加えた Web サイト構築のためのパターン。

業務アプリケーションでも、性能要件や非機能要件がより求められる場合の基本パターン。

ポイントは、SSL Termination を ELB で終端させると、EC2 instance 側で SSL 証明書の管理や HTTPS 通信時の SSL Handshake が不要となるため、EC2 instance cost を削減できるという点。その他、AMI(Amazon Machine Image)をテンプレとして作って複数 EC2 instance を作成するとかにも言及。

RDS を別々の AZ に冗長化するときは、"Multi-AZ" を使えば簡単に冗長化できるのは、マネージドサービスの利点。ただし、Multi-AZ を利用するとデータ更新処理にかかる時間が長くなる点に注意。

Pattern 3. Intra Net for Performance

Auto Scaling を生かしたプロビジョニング、キャッシュと Aurora を利用して DB アクセスがボトルネックにならないような性能要件を満たすためのパターン。On-Premise 環境と AWS 環境間のネットワーク接続を AWS Direct Connect を利用することで、ネットワークの帯域確保も意識している。

AWS Aurora は、AWS Summit Tokyo 2018 に参加した時にその高可用性と耐障害性、パフォーマンスを支える設計思想に関する講演があったので聞いてきたけれど、裏でかなり独自の仕組みを工夫していて、非常に技術的にも優れたプロダクトという印象を持っている。その一部は、"Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases" という論文や、Blackbelt などで広く公開されているので、興味を持っている方いたら是非読んでほしい。

Pattern 4. Intra Net for Availability

可用性にシビアな業務システムを作るときのパターン。Route 53 で、別々の Region に作成したサイトを障害時に備えてルーティングする仕組みを実現している。例えば、メインの東京リージョンが落ちた場合、バックアップ用のシンガポールリージョンにルーティングする、という工夫。

DB のレプリケーションは、Multi-AZ や S3 の "CRR" (Cross-Region Replication) を用いれば、追加でコードを書く必要なくコードを複製させることができる。

ポイントは、サービスが落ちる前提で設計すること。CloudWatch でメインサイトをモニタリングしつつ、EC2 の自動復旧させる仕組みも利用する。また、Route 53 の自動切り替えは、DNS Failover 機能を使う。

Chapter 2. Storage System

Pattern 5. Backup

AWS Storage Gateway を利用した On-Premise 環境におけるデータの S3 バケットへのバックアップや、Amazon Glacier を利用した長期保管など、バックアップ関連のパターンを紹介した節。ここでも、先に紹介された AWS Direct Connect を使って、バックアップやリカバリー要件を満たす選択もある。

Pattern 6. File Server

EC2 instance に NFS server を構築する他、複数の EC2 からマウントできる共有ファイルシステムAmazon EFS を利用したファイルサーバの事例が紹介されている。Amazon EFS は、先日の AWS Summit Tokyo 2018 でも、Tokyo Region にきたことが話題となっていた。また、Amazon WorkDocs を利用したドキュメントの共有も紹介されていた。

Chapter 3. Data Warehouse

Pattern 7. Analysis for Structured Data

Redshift を中心にした分析システムの構成パターン。Redshift には COPY 命令を用いて S3 からロードする。

Pattern 8. Analysis for Un-Structured Data

Fluentd で収集したアクセスログを S3 Bucket に読み込み、Amazon EMR でログデータを整形、整形後のデータを Redshift に取り込み、Tableau で分析するという一連の流れ。Web アクセスログやアプリケーションログを分析するためのパターンの一つ。Tableau は自社でも使っているが、基本的な使い方さえ覚えれば、SQL を書けない社員もダッシュボードを作れるし、比較的高機能だし、非常に便利。

ETL の Transform 部分である EMR の部分はいくつか選択肢があるだろうけれど、EMR は使ったことはない。

Chapter 4. Cloud Native

Patten 9. Serverless Infrastructure

典型的なサーバレス Web システムの構成。静的リソースは CloudFront からの S3 経由で、動的リソースは CloudFront -> API Gateway -> Lamda 経由で返却するパターン。永続化するデータは、とりあえずなんでもよいので外部ストレージに Lambda から保存すればよくて、この本では RDS が紹介されていた。この例では、Lambda Function 作成用の開発向け EC2 instance を立てる例が紹介されていたが、今は Serverless Framework や SAM を使えば良いと思う。

このパターンの場合、Lambda は stateless のため、何らかの状態を保存したい場合は RDS や DynamoDB, S3 などの外部リソースを使う必要がある。要件に応じた外部ストレージを使えば良い。

Chapter 5. Application Development

Patten 10. Server Application Rapid Development

CodePipeline や CodeDeploy を利用することで、CI や自動デプロイを自動化するためのパターン。EC2 instances は ECS を用いて、コンテナーを実行するクラスターを管理している。

Patten 11. Mobile Application Rapid Development

アプリケーション部分は他の節とそこまで違いはないが、Amazon CloudFormation を用いて海外拠点でも日本同様の開発環境を即時に構築できる工夫や、Amazon Device Farm を利用した自動テストの実行、AWS Mobile SDK を利用する開発事例などが盛り込まれた Pattern.

Chapter 6. Hybrid Cloud

Patten 12. Integration with On-Premise Environment

On-Premise 環境とのハイブリッド AWS クラウド環境を築くための工夫が盛り込まれた Pattern. Direct Connect を用いたネットワーク通信路の確保や、VM Import を用いた災害時のサイト環境構築、Auto Scaling & CloduWatch を用いたピーク時のオフロード環境など、今までの節の工夫を総合的に盛り込んだ事例紹介となっている。

Reading Notes of 5th Chapter of "Writing An Interpreter in Go"

Recently I have written a reading node blog post of "Writing An Interpreter in Go".

http://itiskj.hatenablog.com/entry/2018/06/19/083208

After posting the article, I found that the author kindly publish a "lost" chapter - which is about implementing macro features - online. This is really a good chapter, and you can figure out what Macro is, why Macro is necessary in which situations, and how Macro can be implemented.

https://interpreterbook.com/lost/

Here is the PR which implements the macro feature. Just for your information.

https://github.com/kenju/go-monkey/pull/4

By the way, the author has recently tweeted that he gonna publish "Writing Compiler in Go" in the near future. I am really looking forward to it.

https://compilerbook.com/

eslint-plugin-compat のメンテナになった

https://github.com/amilajack/eslint-plugin-compat

仕事で利用しているライブラリの一つで、広告表示の JavaScript SDK の互換性担保のために最近入れたもの。

ブラウザ互換の問題で広告表示ができない、といったクリティカルな問題は避ける必要があって、静的解析の段階でブラウザ互換性に問題のある場合を検出しよう、というのが動機で導入した。

Babel でコンパイルすればいいじゃん、という意見もありかもしれないが、システムの要件上 SDK のサイズを可能な限りまで低く抑える必要があり、Polyfill やガードは最小限にしたい。もちろん Babel は使っているが、core-js を入れてまるっと Polyfill を入れる、といったことはできない。

そんなこんなで使い始めたものの、割とバグや機能不十分なところが多くて、またメンテナが忙しくて反応が悪かったので、パッチを投げたり他の人のイシューを助けてあげたりしていた結果、メンテナになった。

気軽にバグ報告や PR お待ちしております 😉

https://github.com/amilajack/eslint-plugin-compat/issues

Reading Notes of "Writing An Interpreter in Go"

I have just finished reading & writing sample codes "Writing An Interpreter in Go".

https://interpreterbook.com/

This is really a great book, especially because:

  • You can write an interpreter from the scratch, with unit testing
  • You can understand how interpreter works, and know related references (keywords, books, blogs, papers, samples, etc.)
  • The volume of the book & sample codes is appropriate (not too much, not too thin)

This book is going to be published in Japanese soon.

Go言語でつくるインタプリタ

Go言語でつくるインタプリタ

Here is my repository for go-monkey:

https://github.com/kenju/go-monkey

"Header Bidding" について会社ブログに書きました

Techlife に Header Bidding について書きました。

https://techlife.cookpad.com/https://techlife.cookpad.com/entry/2018/06/18/101324

Header Bidding についての導入事例はなかなか日本では見られないので、これを機に増えるといいなと思います。

また、それに限らず広告周りの技術的詳細について積極的に発信して、活発な議論をしていけたらと思います。

『情熱プログラマー』を読んだ。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

久々に、技術書以外の書籍を読んだ。Soft Skills 以来な気がする。

ハッカーと画家』を学生の頃に読んで、エンジニアリングに熱中していた頃のことを思い出すような、清々しいくらいまっすぐな精神論と、シビアに現実と仕事を見返すことのできる視点を授けてくれる、良い本。

キャリアの中で何回か読むんだろうけど、そのたびにそのとき迷っていたり悩んでいたりすることの、何かしらの考えるヒントをくれる、そんな本。

「自分の知性に投資しよう」とか、「魚の釣り方を学ぶ」「一に練習、二に練習」とか、割と自分の中では当たり前だと思っている章もあったけれど、それに対して著者なりの独特な視座や経験を踏まえた意見が知れたのは、刺激になった。

「コーディングはもう武器にならない」「デイリーヒット」「保守作業の真価を知る」「8時間燃焼」「すでに時代遅れである」「君はすでに職を失っている」あたりの節は、完全に自分になかった視点というか、ハットさせられた部分。

エンジニアリングを初めてだいぶ長い時間が経ってきたけれど、プロのエンジニアとして働き続け、成果を出し続けるためには、本当に幅広い視点も努力も必要で、最近必死にもがいていた自分の姿を、少し言語化・体系化できる言葉を得た感じ。それと同時に、やみくもすぎて失敗した経験を考え直すヒントもくれた。

良い本でした。

まつもとりースタイルの話がとても良かった

良かった。語彙力少ないけど、とてもよかった。特にこのスライド。好きなことをやり続けていいんだ、他人から間違ったと言われても自分を信じてやり続ければいいんだ、という、胸の熱くなる話。

そこで実際に一歩踏み出すからこそ、頂が見えてくるんだと思う。実際に一歩踏み出してみないと、失敗もできないし、confort zone を抜けて挑戦しないと、成長もできないからね、という話。