2. 背景 多様な入力文字列を構文解析する必要性 （色々なフォーマットの）設定ファイル Webのクローリング "Cargo cult parsing" (from Yacc is dead) の流行 Googleで検索して正規表現を拾ってきて、テキトウにコピー ＆ペーストしてパーザを作ること 「だいたいの入力に対してそれなりにうまく働く」不完全なパー ザ Cargo cult parsingを追放せよ！ 3. 構文解析って何？ 一言でいうと： 入力文字列を木構造（Abstract Syntax Tree) に組み立てる捜査 二種類に分けられる 自然言語の構文解析 構文解析の結果あいまい性が生じることがある 非自然言語の構文解析 ←今回扱うもの 構文解析の結果あいまい性が生じない 4. 様々な構文解析アルゴリズム CYK - O(n
はい、"古きよき時代から来ました、真面目なSE、真面目にSE" CTO @bash0C7 です。 最近、アニメイトラボの技術陣ではじめた「超高速！技術チーム読書会」についてご紹介します。 進め方 20分という制限時間の中で1人1冊本を読みつつ付箋にメモ書きを残し、10分で互いのメモ書きを共有するというスタイルの読書会です。 これをデイリーで回しています。 1回の読書会では別の本を読みますが、その次の会は互いの本をメモ書きとともに交換して読むようにしていて、共通の知識の習得と問題意識の共有に務めています。 例え1冊全部読めなくても、毎回ごとに違う本を読むようにしています。1回1冊完結でリズムよく進めるためです。 タイトルの由来 歴史ものの作品が好きなのですが、先頃超高速！参勤交代という小説を読みました。映画化もされたのでご存知の方も多いかと思います。 https://www.amazon.c
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
Java 8 lambdas and the builder pattern
I’ve found recently that I’m using the builder pattern more and more. Combined with JAXB schema generated objects builders can get pretty verbose as you end up writing loads of setting methods on your builder. I recalled once seeing a Groovy builder pattern which used closures to implement the builder pattern. Of course, now Java comes with such functionality of its own, so I figured it was time t
プログラミング言語Rustのα版が出たので遊んでみようかなという。（と言ってやってることはRustである必要性が全然ないけど） ここで使っている環境はOS X 10.9.5 （アーキテクチャはx86_64）で、C++コンパイラはClangである。ここでやっているのは激しく環境依存なのだが、まあでもコンパイラがGCCかClangなら多くの環境で上手くいくんじゃないかと思う（知らん）。 背景 Rustはネイティブコードにコンパイルする言語である。ネイティブコードにコンパイルする多くの言語と同じように、RustからはC言語の関数を呼び出せる（こういう風に別のプログラミング言語の関数を呼び出すインターフェースをFFIという）。RustのFFIの詳細はThe Rust Foreign Function Interface Guideに書かれている。 まあ、ネイティブコードにコンパイルする言語がC言語
7/27に開かれたLisp Meetup #30で「Clojureシンタックスハイライター開発から考えるこれからのLispに必要なもの」というタイトルで話してきました。 Clojureシンタックスハイライター開発から考えるこれからのLispに必要なもの from sohta 内容としては、去年のShibuya.lispのテクニカルトークで話した内容を重点をズラして焼き直したものです。終わった後にいくつか意見をいただきましたが、絶対数は多くないのでどう受け止められているのかはちょっと気になるところです。 「これからのLispに必要なもの」とタイトルにはあるものの、具体的に「これが必要だ」と言えてないのが残念な感じですが。。。この発表でいいたかったのは、「LispコードをCASEツールで解析できる対象にしていきませんか」という提案です。 ICSE勉強会なんかの話を聞いていると、他の言語(特にJ
計画したのは半年以上前、検証は 2 ヶ月かかった。 結果的には CPU 使用率は半分になり性能は倍になった。もちろん、本番で、だ。 これから徐々に CPython 環境を PyPy 環境へと置き換えていく。PyPy の最大の魅力はその性能だろう。性能が大きく上がるため、既存環境にかかっているサーバ費用を削減することが出来る。 ただ、注意して欲しいのは PyPy はとてつもなくメモリーを消費する。 Python 環境でパフォーマンス向上を狙うには PyPy はとてもよい選択肢だと思う。とても安定しているし、互換性が本当に高い。 Python + Django という環境で、2 倍性能を上げることはそうそう出来ない。 ただ、PyPy が最後の砦ではあるので、これ以上のパフォーマンスを望む場合は言語を変更する必要がある。Golang なのか Elixir なのか。 PyPy を導入したことで、次
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
