『Writing An Interpreter In Go / Go言語でつくるインタプリタ』 #golang - razokulover publog
Writing An Interpreter In Goという本を読んだ。 この本はMonkeyという言語のインタプリタをGo言語で実装するという内容。 全編英語だが、200ページほどだし語り口も面白くてわかりやすいので読みやすい。 流れとしては大きくLexer・Parser・Evaluaterの章に分かれていて、それぞれ字句解析〜抽象構文木〜評価器をGoの標準機能だけで実装していく感じ。 Parserの部分ではyaccなどの既存ツールを使わずにPratt ParserというJS Lintでも使われている手法を用いて実装していくところが特に面白かった。 Pratt Parserについてはググってもあんまり情報が出てこなかったけど、いくつか英語のエントリがあって特に下記のPythonで解説してくれてるやつがわかりやすかった。 Top-Down operator precedence pars
Writing An Interpreter In Rust して、Wasm で動かしてみた - wadackel.me
はじめに最近 Rust に興味が湧いて少しずつ触ってみています。学習用に何かガッツリと取り組める題材が欲しいなぁと思い、Writing An Interpreter In Go という本にある Monkey というプログラミング言語の Go 実装を Rust で書き直す、ということをやってみました。 そして、Rust で書き直しただけでは少し物足りない感じがしたので、先の本には登場していない要素として Formatter 及び、wasm32-unknown-unknown をターゲットに Wasm へコンパイルしブラウザで動作させるところまで実装しました。 ちなみに Writing An Interpreter In Go は、既に様々な方が読まれているような有名な本なので特別紹介はしませんが、かなりの良書なので「読んだことない！」という方は是非読んでみると面白いかもしれません。 『Wri
Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 | Amazon Web Services
Amazon Web Services ブログ Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかも
言語処理系勉強会に参加してきた | κeenのHappy Hacκing Blog
κeenです。言語処理系勉強会 Vol.1 に参加してきました。そこでの@omochimetaruさんのSwiftのGenericsとProtocolの実装の話が面白かったので少し感想を。 Javaのジェネリクスは型消去で実装されており、全てのジェネリクスを1関数でまかなえます。一方で統一的に扱うために参照型しかジェネリクスに使えず、プリミティブの取り回しに苦労します。 C++のテンプレートやRustのジェネリクスは型毎に実装を作るのでどんな型でも扱えますし、高速です。代わりに関数の数が増えてバイナリサイズが大きくなりがちです。 Swiftはその中間ようなアプローチを取っていました。 Swiftのジェネリクスの話を要約すると、 ジェネリクス関数には値型も全て参照になって渡される。ただし型のメタデータ(Metatype)を渡してゴニョゴニョして失われた型情報(Value Witness Ta
セキュリティ インシデント flatmap-stream@0.1.1 と npm-run-all での対応 - Qiita
人気のある npm パッケージ event-stream (DL数: 2M/週) が悪意ある攻撃に利用されるというセキュリティ インシデントがありました。 私が管理する npm-run-all (DL数: 440K/週) も間接的に event-stream に依存していたため、インシデントの詳細と私の対応について触れておきます。 何をすべき? あなたのプロジェクトが event-stream に依存している場合は、この依存を削除し、代替手段を探すと良さそうです。event-stream の作者は、このパッケージをメンテナンスしないと明言しています。ただ、これだけ騒ぎになったので、信用できる誰かが引き継ぐ可能性はあります。 [編集(2018/11/30)] 現在は npm 社がパッケージ管理を引き継いでいます。ただ、リポジトリは凍結されており、今後変更されることはないでしょう。 次に、あな
2018/11/27に判明したnpmパッケージ乗っ取りについて - Qiita
概要 event-streamというnpmパッケージに攻撃コードが混入されました。攻撃コードはflatmap-streamというパッケージに含まれており、event-stream パッケージはこの flatmap-stream への依存性を追加される形で間接的に攻撃コードの実行を行う状態になっていました。 攻撃コードが分析された結果、copayというBitcoinウォレットからクレデンシャルを盗むことを目的とされていたことが確認されています。 参考リンク 調査が行われているGitHub Issue HackerNewsスレッド Details about the event-stream incident - The npm Blog 影響をうけたパッケージ event-stream@3.3.6 flatmap-stream@0.1.1 flatmap-stream@0.1.1 パッケージ
NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Websites in 2018
ニュースレターの購読 我々からのニュースやお得な情報をいち早く知りたいですか? 毎週興味深い情報を送らせていただきます。スパムは送りません。あなたのメールアドレスを売ったり他人に渡したりすることはありません。 購読する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
